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
