GCC and visibility: one step forward, hit a brick wall

A while back, I posted a workaround that lets Mozilla compile and link properly, working around a bug that is present in GCC 4. I am happy to report that the GCC bug has been fixed on the GCC trunk, 4.1 branch, and 4.0 branch (it should appear in GCC4.0.4 and 4.1.1). I was very excited and immediately went off to build my own GCC and try to build XULRunner with it. No dice! Linking failed in toolkit/library with a similar error as before:

relocation R_X86_64_PC32 against `nsINIParser::Init(nsILocalFile*)' can not be used when making a shared object; recompile with -fPIC

This might look at first glance like the same bug as before, but it’s not: the previous bug was about builtin functions like memcpy, while this bug is about class member functions. It is apparently some bad interaction between #pragma GCC visibility push(hidden) and a class-level attribute which is supposed to override that for default visibility. I managed after several hours of tedium to reduce the testcase to a 30-line .i file and have filed the bug with GCC.

For the moment, though, it appears that GCC4.0.4 and 4.1.1 will not be able to compile Mozilla without the same hacks as I suggested previously:
Configure with the following variable set:

ac_cv_visibility_pragma=no path/to/mozilla/configure –enable-options-here

or put this in your mozconfig:

ac_cv_visibility_pragma=no (Don’t prefix this with ac_add_options!)

Atom Feed for Comments 4 Responses to “GCC and visibility: one step forward, hit a brick wall”

  1. Benjamin Smedberg Says:

    Update: I’ve filed Mozilla bug 334866 to configure-test for broken compilers until this is fixed.

  2. BSBlog » Blog Archive » Pick a Compiler, but Not Any Compiler Says:

    [...] I also have some interesting developments to report in GCC-land: a large patch by Jason Merrill (RedHat) landed on GCC trunk which fixes a whole bunch of GCC visibility bugs (previous post about these issues). Unfortunately, Jason added some additional restrictions on the use of types with hidden visibility which means that Mozilla doesn’t even compile using GCC trunk. I’ve been in email contact with Jason and hopefully we’ll have things worked out shortly. [...]

  3. Werner Flamme Says:

    Ben, your tip with “ac_cv_visibility_pragma=no” helped me to get behind the “memset” problem, but now I’m stuck with an error like you show above: /usr/lib64/libXft.a(xftdpy.o): relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object; recompile with -fPIC.
    I added -lXft to the XLIBS line in config/autoconf.mk, but to no avail. Any hints? I do not see a gcc newer than mine [gcc version 4.0.3 20051024 (prerelease) (SUSE Linux)] in SUSE’s repositories.

  4. Building FF 2.0.0.x on Ubuntu 8.x « micadeyeye’s Weblog Says:

    [...] “final_link_failed” / NSGLUE_WARNING error http://benjamin.smedbergs.us/blog/2005-10-27/gcc-40-workaround/ — Got the error fixed by adding “ac_cv_visibility_pragma=no” to my .mozconfig http://benjamin.smedbergs.us/blog/2006-03-28/gcc-and-visibility-one-step-forward-hit-a-brick-wall/ [...]

Leave a Reply