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)? Does it have a relocation against that symbol (see readelf -r output)? Ian
