This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Native GCC 4.9.0 Build Fails Building/Linking libgcc_s_so with Undefined Symbol
- From: Cyd Haselton <chaselton at gmail dot com>
- To: Kai Ruottu <kai dot ruottu at wippies dot com>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Thu, 20 Nov 2014 09:20:17 -0600
- Subject: Re: Native GCC 4.9.0 Build Fails Building/Linking libgcc_s_so with Undefined Symbol
- Authentication-results: sourceware.org; auth=none
- References: <CAHu5PrZzf7wa1Y1mWjyb_XrLkksCw04PLRKQNNBvy-tsogGWdw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 11 dot 1411162341210 dot 1590 at laptop-mg dot saclay dot inria dot fr> <CAHu5Prb3OUk3SyDkwzzJ7NxVvh=2uNYeV4ch2O4Q1moACS-N=w at mail dot gmail dot com> <CAH6eHdS--Rd8WKedsCpwFyVF__xbaKda6FQLVxpkUM1maMogDw at mail dot gmail dot com> <CAHu5PraQfHcbCYhsF9gqMKsfNiLtOHdpfOB7_U4uWGUvAY7_zA at mail dot gmail dot com> <CAHu5PrYVdg=Kmb4aGwtoz++EPrAuVKBbZzUJ48j_+CRdV7buEg at mail dot gmail dot com> <CAH6eHdSL6OMD8eXicCsz_+3xoAQc+Km+DRqasuBZ=xA0SaoZPg at mail dot gmail dot com> <546D1646 dot 90506 at wippies dot com> <CAHu5PraNJwTdE7=bAfQdox7VcxDE-e=tpmoGXLNRtouyuWfdUQ at mail dot gmail dot com> <546E00BC dot 4000407 at wippies 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...