Closed Bug 741348 Opened 9 years ago Closed 8 years ago

crashreporter failing to build with current trunk

Categories

(Firefox Build System :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla15

People

(Reporter: jik, Assigned: glandium)

References

Details

Attachments

(1 file)

I'm getting a build failure in crashreporter on Linux:

../google-breakpad/src/common/linux/file_id.o: In function `operator delete(void*)':
/mnt/share/build/thunderbird/comm-central/objdir-tb-debug/mozilla/toolkit/crashreporter/google-breakpad/src/common/linux/../../../../../../dist/include/mozilla/mozalloc.h:253: undefined reference to `moz_free'
collect2: error: ld returned 1 exit status
make[7]: *** [crashreporter] Error 1

This is my .mozconfig:

ac_add_options --enable-application=mail
mk_add_options MOZ_MAKE_FLAGS="-j3"
ac_add_options --with-ccache
#mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-release
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-debug
ac_add_options --enable-debug
ac_add_options --disable-optimize

I'm current from the trunk, and I totally blew away objdir-tb-debug and confirmed there were no weird files sitting around in the source tree. (To be totally accurate: I did all that yesterday after getting this failure for the first time; then got it again; then did "python client.py checkout" this morning and I'm still getting it, but I didn't blow everything away again this morning.)
Most likely a core issue.
Product: Thunderbird → Core
QA Contact: build-config → build-config
That's an interesting problem, and I actually don't understand why we haven't hit it much earlier...

toolkit/crashreporter/client/Makefile.in has STL_FLAGS=, which does the right thing and avoids using mozalloc for operator new/delete, etc. But it also links with breakpad_linux_common_s (and similar libs for other platforms) that are *not* built with STL_FLAGS=, so they do have a dependency on mozalloc. And since these libs are also linked in libxul.so, they are expected to have that dependency on mozalloc...
Is there a workaround? I assume that this isn't breaking everyone's build, because otherwise it would be critical and would have been fixed by now. So why is mine breaking, and what can I change in my build to unbreak it?

It's making it sort of difficult to work on Thunderbird when I can't build it...
You should be able to use ac_add_options --disable-crashreporter as a workaround.
I got this the first time now with mozilla-beta (12) but only with gcc 4.7. Does that make sense?
(In reply to Mike Hommey [:glandium] from comment #2)
> toolkit/crashreporter/client/Makefile.in has STL_FLAGS=, which does the
> right thing and avoids using mozalloc for operator new/delete, etc. But it
> also links with breakpad_linux_common_s (and similar libs for other
> platforms) that are *not* built with STL_FLAGS=, so they do have a
> dependency on mozalloc. And since these libs are also linked in libxul.so,
> they are expected to have that dependency on mozalloc...

So what would be the right approach to fix this? gcc 4.7 (which seems to expose that issue) is the compiler used for our next distribution which is not far away. So I'd need to fix it somehow or stop temporarily shipping the crashreporter :-(
Experiencing the same error on a Linux64 box with Arch Linux. Been happening since I upgraded the distro. I tried downgrading gcc and g++ to 4.4, but no joy there.
Here is the best part: operator delete(void*) from file_id.o is the only problem preventing from linking, and it's not even called from anywhere in file_id.o. The second best part is that mozalloc.h defines operator delete(void *) as always inlined, so the function shouldn't even be there.
... and this happens because GCC 4.7 defines this in <new>:
void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
  __attribute__((__externally_visible__));

Removing that attribute in the system header makes gcc 4.7 not include that useless symbol, and the build to succeed.
I filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341 to have some light on the issue on the gcc side. On our end the possible workarounds:
- build file_id.o without -std=gnu++0x. Should be okay because file_id.cc doesn't use much STL.
- avoid including algorithm from file_id.cc (only std::min is used, and that's trivial to implement).
- build file_id.o with STL_FLAGS=. This should be safe, as it doesn't use operator new or operator delete.
- others more complicated workarounds.
Assignee: nobody → mh+mozilla
Fantastic, I'm a newcomer and I just ran into this bug. I can confirm that Mike Homney's patch works on my system (Arch Linux x86_64).
Attachment #623623 - Flags: review?(ted.mielczarek) → review+
https://hg.mozilla.org/mozilla-central/rev/ad167725cba5
Target Milestone: --- → mozilla15
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 759668
how can we get this into Aurora?
Comment on attachment 623623 [details] [diff] [review]
Work around crashreporter client build failure with gcc 4.7

[Approval Request Comment]
Bug caused by (feature/regressing bug #): compiler breakage (newer gcc)
User impact if declined: can't compile on Fedora 17 (and other gcc 4.7.0)
Testing completed (on m-c, etc.): tested here. Works.
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:
Attachment #623623 - Flags: approval-mozilla-aurora?
Comment on attachment 623623 [details] [diff] [review]
Work around crashreporter client build failure with gcc 4.7

[Triage Comment]
Looks very low risk, and any fallout should be immediately obvious as part of the build. Approving for Aurora 14.
Attachment #623623 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.