Last Comment Bug 741348 - crashreporter failing to build with current trunk
: crashreporter failing to build with current trunk
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86_64 Linux
: -- normal (vote)
: mozilla15
Assigned To: Mike Hommey [:glandium]
:
: Gregory Szorc [:gps]
Mentors:
: 759668 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-02 05:38 PDT by Jonathan Kamens
Modified: 2012-05-30 16:32 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Work around crashreporter client build failure with gcc 4.7 (828 bytes, patch)
2012-05-14 03:24 PDT, Mike Hommey [:glandium]
ted: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Jonathan Kamens 2012-04-02 05:38:42 PDT
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.)
Comment 1 Mark Banner (:standard8, afk until Dec) 2012-04-02 06:00:08 PDT
Most likely a core issue.
Comment 2 Mike Hommey [:glandium] 2012-04-03 01:42:10 PDT
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...
Comment 3 Jonathan Kamens 2012-04-04 20:34:45 PDT
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...
Comment 4 Ted Mielczarek [:ted.mielczarek] 2012-04-05 07:17:21 PDT
You should be able to use ac_add_options --disable-crashreporter as a workaround.
Comment 5 Wolfgang Rosenauer [:wolfiR] 2012-04-16 01:05:48 PDT
I got this the first time now with mozilla-beta (12) but only with gcc 4.7. Does that make sense?
Comment 6 Wolfgang Rosenauer [:wolfiR] 2012-04-18 04:04:47 PDT
(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 :-(
Comment 7 Pranav Ravichandran [:pranavrc] 2012-04-20 04:53:13 PDT
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.
Comment 8 Mike Hommey [:glandium] 2012-05-14 02:35:27 PDT
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.
Comment 9 Mike Hommey [:glandium] 2012-05-14 02:42:53 PDT
... 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.
Comment 10 Mike Hommey [:glandium] 2012-05-14 02:48:01 PDT
And that's because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
Comment 11 Mike Hommey [:glandium] 2012-05-14 03:21:51 PDT
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.
Comment 12 Mike Hommey [:glandium] 2012-05-14 03:24:36 PDT
Created attachment 623623 [details] [diff] [review]
Work around crashreporter client build failure with gcc 4.7
Comment 13 Isaac Aggrey 2012-05-14 08:34:07 PDT
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).
Comment 14 Mike Hommey [:glandium] 2012-05-15 10:02:08 PDT
https://hg.mozilla.org/mozilla-central/rev/ad167725cba5
Comment 15 Hubert Figuiere [:hub] 2012-05-29 23:32:58 PDT
*** Bug 759668 has been marked as a duplicate of this bug. ***
Comment 16 Hubert Figuiere [:hub] 2012-05-29 23:34:05 PDT
how can we get this into Aurora?
Comment 17 Hubert Figuiere [:hub] 2012-05-29 23:59:54 PDT
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:
Comment 18 Alex Keybl [:akeybl] 2012-05-30 16:32:27 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.