Linker Error When Building gnat 4.6.0

[Shea Levy]

On 03/29/2011 04:38 PM, Ian Lance Taylor wrote:
> Shea Levy<shea@shealevy.com>  writes:
>
>> On 03/29/2011 04:00 PM, Ian Lance Taylor wrote:
>>> Shea Levy<shea@shealevy.com>   writes:
>>>
>>>> On 03/29/2011 03:42 PM, Ian Lance Taylor wrote:
>>>>> Shea Levy<shea@shealevy.com>    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
Found it:

000000000000098a  0000002800000002 R_X86_64_PC32          
0000000000000000 simple_object_set_big_16 - 4

How should I proceed? Should I file a bug?

~Shea