When "#pragma GCC visibility push" is used on builtin functions, it may not be properly handled if "#pragma GCC visibility pop" is missing.
Created attachment 8315 [details] A testcase /export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/ -O2 -fPIC -c -o foo.o foo.c /export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/ -o libfoo.so -shared foo.o foo.o: In function `foo': foo.c:(.text+0x5): undefined reference to `memcpy' /usr/local/bin/ld: foo.o: relocation R_X86_64_PC32 against `memcpy' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [libfoo.so] Error 1 The problem is gcc mishandles #pragma GCC visibility push(hidden) #pragma GCC visibility push(default) typedef long unsigned int size_t; extern void *memcpy (void *, const void *, size_t); #pragma GCC visibility pop and thinks memcpy is hidden. It only happens to builtin functions. When memcpy is renamed to bar, gcc is OK.
In case anyone is curious, this causes the Mozilla HEAD build to fail [at least with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on two separate occasions, once with nsprpub and once with libmozjs.so. Removing the use of "#pragma GCC visibility" statements causes the source to build and link as expected.
(In reply to comment #2) > In case anyone is curious, this causes the Mozilla HEAD build to fail [at least > with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on > two separate occasions, once with nsprpub and once with libmozjs.so. Removing > the use of "#pragma GCC visibility" statements causes the source to build and > link as expected. It cannot be causing a non modified gcc 3.4.3 to fail as 3.4.3 does not include this pragma at all, it is only included with 4.0.0 and above.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html FYI, gcc 3.4 from RH does include this pragma.
$ gcc --version gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17) I stand corrected, Fedora Core 3 must be back-porting some of that functionality. Should I open a bug with them pointing to this, or is it just water under the bridge now?
RH bug is at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150157
(In reply to comment #4) > A patch is posted at > > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html > > FYI, gcc 3.4 from RH does include this pragma. this patch ices gcc-4.1-20050522 bootstrap. ../../gcc/libgcc2.c: In function '__absvsi2': ../../gcc/libgcc2.c:215: internal compiler error: tree check: expected class 'declaration', have 'expression' (call_expr) in expand_builtin, at builtins.c:6260
Created attachment 9035 [details] New patch This fixes a problem in HJs patch (which doesn't look at the fndecl of the builtin, but at the call_expr).
I can confirm that attachment 9035 [details] fixes the mozilla compile issues with GCC 4.0/4.0.1/trunk.
Created attachment 9720 [details] Failure even with the latest patch I'm wrong. attachment 9035 [details] fixes the compile errors in the main mozilla tree, but does not fix the errors in NSPR. Attached is the preprocessed source that's failing. This was compiled with -pipe -ansi -Wall -pthread -g -fno-inline -fPIC
I'm using gcc 4.0.2 with patches for gcc pr19664, pr20297 and pr19520. The testcase from this bug passes without problems. Still firefox beta2 and current CVS fails to build. I talked to the mozilla guys and they asked me to report it here. Any ideas what might be wrong? x86_64-pc-linux-gnu-gcc -DGENTOO_NSPLUGINS_DIR=\"/usr/lib64/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib64/nsbrowser/plugins\" -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=athlon64 -pipe -fPIC -Wno-return-type -w -pthread -pipe -DNDEBUG -DTRIMMED -ffunction-sections -Os -fPIC -shared -Wl,-h -Wl,libmozjs.so -Wl,-R/usr/lib64/mozilla-firefox -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o -Wl,-O1 -Wl,-R/usr/lib64/mozilla-firefox -lm -ldl -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: jsapi.o: relocation R_X86_64_PC32 against `memcpy@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status gmake[3]: *** [libmozjs.so] Error 1 gmake[3]: Leaving directory `/var/tmp/portage/mozilla-firefox-9999/work/mozilla/js/src' gmake[2]: *** [libs] Error 2 gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-9999/work/mozilla/js' gmake[1]: *** [tier_2] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-9999/work/mozilla' make: *** [default] Error 2 The 9999 version means that it's a CVS build in gentoo. Binutils is version 2.16.1 and glibc is 2.3.5.
I'm not sure, but I'm getting this bug as well, but it maybe out of date. On the last part about the mozilla bail out, if you add this to your mozconfig it might get it to build correctly. ac_cv_visibility_pragma=no
Still seeing this problem w/ current 4.1 branch
Subject: Bug 20297 Author: jason Date: Wed Mar 22 04:20:52 2006 New Revision: 112270 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112270 Log: PR middle-end/20297 * expr.c (init_block_move_fn): Force default visibility. (init_block_clear_fn): Likewise. * builtins.c (expand_builtin_fork_or_exec): Likewise. * targhooks.c (default_external_stack_protect_fail): Likewise. Added: trunk/gcc/testsuite/gcc.dg/visibility-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/targhooks.c
Subject: Bug 20297 Author: jason Date: Wed Mar 22 04:22:40 2006 New Revision: 112271 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112271 Log: PR middle-end/20297 * expr.c (init_block_move_fn): Force default visibility. (init_block_clear_fn): Likewise. * builtins.c (expand_builtin_fork_or_exec): Likewise. * targhooks.c (default_external_stack_protect_fail): Likewise. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/expr.c branches/gcc-4_1-branch/gcc/targhooks.c
Subject: Bug 20297 Author: jason Date: Wed Mar 22 04:23:10 2006 New Revision: 112272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112272 Log: PR middle-end/20297 * expr.c (init_block_move_fn): Force default visibility. (init_block_clear_fn): Likewise. * builtins.c (expand_builtin_fork_or_exec): Likewise. * targhooks.c (default_external_stack_protect_fail): Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/visibility-11.c
Subject: Bug 20297 Author: jason Date: Wed Mar 22 04:50:31 2006 New Revision: 112273 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112273 Log: PR middle-end/20297 * expr.c (init_block_move_fn): Force default visibility. (init_block_clear_fn): Likewise. * builtins.c (expand_builtin_fork_or_exec): Likewise. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c branches/gcc-4_0-branch/gcc/expr.c
Subject: Bug 20297 Author: jason Date: Wed Mar 22 04:55:18 2006 New Revision: 112274 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112274 Log: PR middle-end/20297 * expr.c (init_block_move_fn): Force default visibility. (init_block_clear_fn): Likewise. Modified: branches/redhat/gcc-3_4-branch/gcc/ChangeLog branches/redhat/gcc-3_4-branch/gcc/expr.c
fixed a while back