Re: Native GCC 4.9.0 Build Fails Building/Linking libgcc_s_so with Undefined Symbol

[Cyd Haselton <chaselton at gmail dot com>]

On Thu, Nov 20, 2014 at 8:54 AM, Kai Ruottu <kai.ruottu@wippies.com> wrote:
> 20.11.2014, 15:37, Cyd Haselton kirjoitti:
>>
>> On Wed, Nov 19, 2014 at 4:14 PM, Kai Ruottu <kai.ruottu@wippies.com>
>> wrote:
>>>
>>> 19.11.2014, 20:51, Jonathan Wakely kirjoitti:
>>>>
>>>> On 19 November 2014 18:08, Cyd Haselton wrote:
>>>>>
>>>>> In another attempt to fix this problem, I grepped for dlopen in the
>>>>> build directoryand ran across the following:
>>>>>
>>>>>   From ./gcc/config.log
>>>>>
>>>>> configure:27894: checking for library containing dlopen
>>>>> configure:27925: gcc --sysroot=/usr/gcc-4.8/sysroot -o conftest -Wall
>>>>> -mandroid -mbionic   -static-libstdc++ -static-libgcc
>>>>> -Wl,--dynamic-linker=/system/bin/linker -lc -ldl -lgcc -lm -lsupc++
>>>>> -lgnustl_shared conftest.c  >&5
>>>>> configure:27925: $? = 0
>>>>> configure:27942: result: none required:
>>>>>
>>>>> And this, from liblto_plugin.la:
>>>>> # The name that we can dlopen(3).
>>>>> # Files to dlopen/dlpreopen
>>>>> dlopen=''"
>>>>>
>>>>>
>>>>> It seems to me as though configure needs to pick up libdl (which is
>>>>> the android library to link to for dlopen...though i'm not sure how to
>>>>> make this happen.
>>>>>
>>>>> Thoughts?
>>>>
>>>> It's already linking to libdl, look at the command it used.
>>>>
>>>>
>>> It looks like the 'libgcc/config/t-slibgcc' could need a hack.  The
>>> SHLIB_LINK definition
>>> there has SHLIB_LC which as default is '-lc' but in this special case it
>>> should be defined
>>> earlier as '-lc -ldl'...  Probably making a custom template for the
>>> 'arm*-linux-androideabi'
>>> case in the 'libgcc/config.host' would be the right way to patch the
>>> support
>>> in...
>>
>> Wouldn't the modification need to be in one of the  the gcc/config/..
>> files as well?
>
>
> Yes, adding one 't-' file more where the custom SHLIB_LC is defined could be
> the way.
> Just as there is the 't-libunwind' for overriding the value from
> 't-slibgcc-elf-ver' for some
> case. But only the 'SHLIB_LC = -lc -ldl' would be required there.
>
>> Again...my knowledge of GCC internals is minimal...but I just modified
>> libgcc/config/t-slibgcc so that SHLIB_LINK would include -ldl, re-ran
>> make, and got the same error.
>
>
> Making a logfile from the make could help :
>    make > Logfile 2>&1

I'll give it a shot.  For GCC, it wasn't as clear where SHLIB_LC was
defined as for libgcc.

>> Again...my knowledge of GCC internals is minimal...but I just modified
>> libgcc/config/t-slibgcc so that SHLIB_LINK would include -ldl, re-ran
>> make, and got the same error.
>
>
> Making a logfile from the make could help :
>    make > Logfile 2>&1
> If the '-ldl' is there but the symbol wasn't found then the link order is
> wrong. You should

I will try that.

> look with your 'arm-linux-androideabi-nm' where the dlopen() is undefined.
> Maybe in some
> later linked library?

Do you mean a library that I'm linking with libgcc or a library linked
in the build process?

> The '-lc -ldl' fixes only the undefined symbols in
> libc and in the earlier
> linked objects and libraries, not those being linked later...
> So the link
> command used for
> linking the 'libgcc_s.so' must be investigated.
>

The link command for libgcc_s.so has a ton of objects, prefixed by
some -Wl,- flags and followed by 'libgcc.a -lc', then a bunch of
additional commands separated by &&.  The most recent make showed that
the command linking libgcc_s.so had been updated so that -ldl was
added ('libgcc.a -lc -ldl').

Additional information:  The config.log for libgcc shows the same
error (fakechroot: dlopen: undefined symbol: dlopen) occurs at
configure:3389 (which is funny because I'm a Windows admin by trade).
I'm not sure what the conftest contents are, but it attempted to run
./gcc/xgcc -B/dir -B/dir -B/dir -isystem /dir --sysroot=/path/to/sysroot CFLAGS


>> I could run make distclean and start over, but I'm working on an
>> Android tablet so unless it's absolutely necessary I'd like to avoid
>> doing so; it would take about half a day to get results.
>>
>
> I haven't a "native" Android platform handy but I could try a new
> crosscompiler. After
> maybe updating the Android NDK libraries. Currently I have something from
> 2013 and
> the newest 'arm-linux-androideabi' target GCC is 4.8.2 or something... So I
> myself could
> also see the problem with 4.9.x...

I used the NDK to cross compile both 4.7.x and 4.8.x to the Android
platform I'm working in; I had to go back to 4.7.0 when bootstrapping
4.8. on device because my original cross-compile was only for the C
and C++ languages.  I could go back and duplicate my steps to see what
changed between 4.8 and 4.9 but I've only so much space on the
tablet...