741348 - crashreporter failing to build with current trunk

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jonathan Kamens]

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)]

Most likely a core issue.

Comment 2

[Mike Hommey [:glandium]]

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]

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

[(not currently active) Ted Mielczarek]

You should be able to use ac_add_options --disable-crashreporter as a workaround.

Comment 5

[Wolfgang Rosenauer [:wolfiR]]

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]]

(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]]

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]]

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]]

... 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]]

And that's because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594

Comment 11

[Mike Hommey [:glandium]]

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]]

Attachment: Work around crashreporter client build failure with gcc 4.7

Comment 13

[Isaac Aggrey]

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]]

https://hg.mozilla.org/mozilla-central/rev/ad167725cba5

Comment 16

[Hubert Figuiere [:hub]]

how can we get this into Aurora?

Comment 17

[Hubert Figuiere [:hub]]

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]]

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.