Shea Levy <shea@xxxxxxxxxxxx> writes: > On 03/29/2011 04:00 PM, Ian Lance Taylor wrote: >> Shea Levy<shea@xxxxxxxxxxxx> writes: >> >>> On 03/29/2011 03:42 PM, Ian Lance Taylor wrote: >>>> Shea Levy<shea@xxxxxxxxxxxx> writes: >>>> >>>>>>> When trying to build GCC 4.6.0 with Ada support, I get the following error: >>>>>>> >>>>>>> ld: ../libiberty/pic/libiberty.a(simple-object-coff.o): relocation >>>>>>> R_X86_64_PC32 against undefined symbol `simple_object_set_big_16' can not >>>>>>> be used when making a shared object; recompile with -fPIC >>>>>>> ld: final link failed: Bad value >>>>>>> make[4]: *** [liblto_plugin.la] Error 1 >>>>>>> >>>>>>> It was my understanding that the pic/ subdirectory of libiberty/ was for a >>>>>>> PIC version of libiberty. This error occurs whether I explicitly export >>>>>>> -fPIC in CFLAGS or not. I have been able to build GCC 4.6.0 successfully >>>>>>> without Ada. >>>>>> The cases where I have seen this are where somebody runs configure, runs >>>>>> make, and then runs configure again in the same directory in a way that >>>>>> changes whether the PIC version of libiberty needs to build. Is it >>>>>> possible that that happened here? >>>>> I'm fairly certain this isn't happening, I automate my builds and >>>>> start with a fresh unpacking each time. I've looked through the build >>>>> logs, and I don't see any configure-like output after building >>>>> starts. Also, there is a file libiberty/pic/libiberty.a after the >>>>> build failure, though I don't know how to check if it has been built >>>>> with PIC. >>>> One simple thing is to check the build logs and see if you see -fPIC >>>> there when building libiberty. To see if libiberty/pic/libiberty.a is >>>> PIC, run readelf -r and look for PLT or GOT relocs (see if the name of >>>> the reloc has the string "PLT" or "GOT"). If you see those relocs, the >>>> code was compiled with -fPIC. >>>> >>>> Looking at the code, I am reminded that simple_object_set_big_16 is >>>> actually a static inline function in a header file #include'd by >>>> simple-object-coff.c. So it's odd that the function was not inlined. >>>> And even if it weren't inlined, it's very odd that it is not defined. >>>> So tell us more about how you are building gcc. What compiler are you >>>> using? Are you using --enable-build-with-cxx? >>>> >>>> Ian >>> For the build logs, I see libiberty being built twice, with everything >>> in the pic/ subdirectory being built with -fpic (not -fPIC). The >>> non-debug relocation sections of readelf -r libiberty/pic/libiberty.a >>> contains many entries with type R_X86_64_PLT32, as well as many with >>> type R_X86_64_PC32 and a few with type R_X86_64_GOTPCREL. The debug >>> relocation sections contain entries of type R_X86_64_32 or >>> R_X86_64_64. >>> >>> I am compiling with GCC 4.5.1, and all libraries on the system were >>> built with that same compiler. My configure flags are as follows: >>> >>> --prefix=/nix/store/z8h0d602w6bhxjdcbvvc57b84dbf744i-gnat-4.6.0 >>> --disable-multilib >>> --with-gmp=/nix/store/ji6py9m9w2ray1bmpkmgig9llj1i2ggf-gmp-4.3.2 >>> --with-mpfr=/nix/store/zy26xh7csglfc5vqb78pj4xi2z3qy9qc-mpfr-3.0.0 >>> --with-mpc=/nix/store/v3r9yi1fnf1v07zqifnvmwbv0mhv3iii-mpc-0.8.2 >>> --with-libelf=/nix/store/mfls8slvmcvg7r1c5k9z1lkcvi4ivwjg-libelf-0.8.13 >>> --disable-libstdcxx-pch >>> --without-included-gettext >>> --with-system-zlib >>> --enable-languages=c,ada >>> --enable-libada >> That all looks entirely reasonable. (The difference between -fpic and >> -fPIC is irrelevant here.) >> >> The error message says >> >> relocation R_X86_64_PC32 against undefined symbol `simple_object_set_big_16' can not be used when making a shared object; recompile with -fPIC >> >> If you look at the file libiberty/pic/simple-object-coff.o, does it >> define the symbol simple_object_set_big_16 (see readelf -s output)? > Yes: > 40: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND > simple_object_set_big_16 >> Does it have a relocation against that symbol (see readelf -r output)? > There are two relocations that might be it, I'm not sure how to tell: > 000000000c62 002800000002 R_X86_64_PC32 0000000000000000 > simple_object_set_big_ - 4 > 000000000c9a 002a00000002 R_X86_64_PC32 0000000000000000 > simple_object_set_big_ - 4 The readelf program has an extremely unfortunate default behaviour, which is to truncate symbol names. Try passing the -w option. This looks like the bug but I have no idea why it is happening. A static inline function should not be discarded if it is referenced without being inlined. Ian
