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!)
April 21st, 2006 at 11:32 am
Update: I’ve filed Mozilla bug 334866 to configure-test for broken compilers until this is fixed.
July 12th, 2006 at 1:44 pm
[…] 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. […]
October 12th, 2006 at 6:46 am
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.
December 12th, 2008 at 7:37 pm
[…] “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/ […]