Re: Linker Error When Building gnat 4.6.0

[Ian Lance Taylor <iant at google dot com>]

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

Ian