crashreporter failing to build with current trunk

RESOLVED FIXED in mozilla15

Status

()

Core
Build Config
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jonathan Kamens, Assigned: glandium)

Tracking

Trunk
mozilla15
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
Component: Build Config → Build Config
Product: Thunderbird → Core
QA Contact: build-config → build-config
(Assignee)

Comment 2

5 years ago
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...
(Reporter)

Comment 3

5 years ago
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.
(Assignee)

Comment 8

5 years ago
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.
(Assignee)

Comment 9

5 years ago
... 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.
(Assignee)

Comment 10

5 years ago
And that's because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
(Assignee)

Comment 11

5 years ago
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)

Comment 12

5 years ago
Created attachment 623623 [details] [diff] [review]
Work around crashreporter client build failure with gcc 4.7
Attachment #623623 - Flags: review?(ted.mielczarek)
(Assignee)

Updated

5 years ago
Assignee: nobody → mh+mozilla

Comment 13

5 years ago
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+
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/mozilla-central/rev/ad167725cba5
Target Milestone: --- → mozilla15
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
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+
You need to log in before you can comment on or make changes to this bug.