Created attachment 31855 [details] test runner Hi *, I originally filed this as Debian #735564 but a user informed me they are also seeing this on other GNU/Linux distributions, and with GCC 4.7.1 on Slackware. Since a while, I’m getting errors like these: `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o I used to be able to avoid them (although, back then, the symbol was named “__i686.get_pc_thunk.bx”) by adding -march=i486, but this no longer helps. Screen log (the files x.sh, x.i and x.sym are attached): tglase@tglase:~ $ mksh x.sh `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o collect2: error: ld returned 1 exit status IMHO, GCC may not mark symbols as discardable that it uses by itself. Adding this to the symbol file is no solution either, as this becomes highly platform- and compiler-dependent.
Created attachment 31856 [details] preprocessed source code
Created attachment 31857 [details] symbols file
Adding extra info. GCC 4.6 (Debian sid) works iff you add -march=i486 but exhibits the same problem (with different symbol) otherwise. GCC 3.4.6 (MirBSD) works.
I don't think this is a GCC bug but rather a bug using objcopy and thinking that will not get rid of hidden global symbols. The .text.__x86.get_pc_thunk.[bc]x symbols are defined as: .section .text.__x86.get_pc_thunk.cx,"axG",@progbits,__x86.get_pc_thunk.cx,comdat .globl __x86.get_pc_thunk.cx .hidden __x86.get_pc_thunk.cx .type __x86.get_pc_thunk.cx, @function __x86.get_pc_thunk.cx: .LFB15: .cfi_startproc movl (%esp), %ecx ret .cfi_endproc .LFE15: .section .text.__x86.get_pc_thunk.bx,"axG",@progbits,__x86.get_pc_thunk.bx,comdat .globl __x86.get_pc_thunk.bx .hidden __x86.get_pc_thunk.bx .type __x86.get_pc_thunk.bx, @function __x86.get_pc_thunk.bx: .LFB16: .cfi_startproc movl (%esp), %ebx ret So they are already hidden so when doing the final link they will not show up in the shared library. The objcopy is removing the symbol names for these section which is invalid as they are comdat and cannot be removed. Really the code should move over to a versioning script instead of using objcopy and that would work much better and be slightly more portable.
Hm, unsure. These versioning scripts are pretty much recent GNU stuff. But if you have input… cvs -d _anoncvs@anoncvs.mirbsd.org:/cvs co -PA -d xchat-randex contrib/hosted/tg/code/xchat-randex
(In reply to Thorsten Glaser from comment #5) > Hm, unsure. These versioning scripts are pretty much recent GNU stuff. Recent as in the last 10 years maybe. But not in the last 5 years. Also they are supported in Solaris and even Darwin too.
objcopy bug filed just recently: https://sourceware.org/bugzilla/show_bug.cgi?id=27931 So closing as moved.
Or it is fixed by https://sourceware.org/bugzilla/show_bug.cgi?id=3182 . Either way it is a binutils objcopy issue and not a GCC one really.