Re: Android Native GCC 4.9.2 Build Fails at Dynamic libgcc

[Cyd Haselton <chaselton at gmail dot com>]

On Wed, Jan 7, 2015 at 7:37 AM, Andrew Haley <aph@redhat.com> wrote:
> On 01/07/2015 01:20 PM, Brian Drummond wrote:
>> On Wed, 2015-01-07 at 12:17 +0000, Andrew Haley wrote:
>>> On 01/07/2015 12:14 PM, Cyd Haselton wrote:
>>>> Here goes.
>>>
>>> You mailer mangled that.  As an attachment please.
>>>
>>> Andrew.
>>>
>>
>> Below is the relevant command I saw in the attachment (most .o filenames
>> redacted)...
>>
>> It ends with
>> fakechroot: dlopen: undefined symbol: dlopen
>> collect2: error: ld returned 1 exit status
>> make: *** [libgcc_s.so] Error 1
>>
>> which I think reinforces your hypothesis that it is the ld program
>> itself which fails, rather than anything in the files being linked.
>>
>> I don't know if Cyd cc'ed you this message...
>> (I'll forward it to the list)
>> ----------------------------------------------------------------------
>>> The following is a quote from the developer who created the
>>> environment I'm using:
>>>
>>>    "Using libfakechroot to virtualize a root filesystem is a bit of a
>>> hack, to be honest, and its weaknesses are easily exposed. Most
>>> obviously, it will only filter dynamic calls to the Bionic C library
>>> (because that was the C library it itself is linked against).
>> ...
>>> I've been in contact with him regarding a number of other ports and
>>> he's confirmed that reverting to static linking would be a pain.
>>>
>>> Also, iIn case anyone reading this is interested:
>>> http://kevinboone.net/kbox2_how_it_works.html
>> ----------------------------------------------------------------------
>>
>> which makes me wonder about Bionic's support for dlopen(). Cyd confirmed
>> that he uses the same binutils version for 4.8 and 4.9 so we may be
>> looking at a failure in a 2-step process
>>
>> (a) 4.9 assumes some capability from ld that 4.8 doesn't, which requires
>> a DLL to be opened
>>
>> (b) fakechroot layered over Bionic is failing to implement that
>> capability (we know from nm that dlopen is undefined in Cyd's
>> libfakechroot.so)
>>
>> Step (a) may be within the remit of gcc-help, what is the difference and
>> can it be worked round) but step (b) probably lies elsewhere : as a
>> first step, enquire about the missing dlopen() in fakechroot.
>
> I think it's now becoming clear what is happening.  Something in ld is
> calling dlopen, and fakechroot prints the error.  But it's not clear to
> me which dlopen does not work in fakechroot.
>
This is probably a stupid question, but here goes:  How many dlopens are there?

> My guess is that the problem is due to link-time optimization.  gcc is
> trying to run -plugin /bld/gcc/builddir-4.9/./gcc/liblto_plugin.so.  4.8
> does not do this.
>
> Maybe fakechroot can be persuaded to produce a decent error message with
> some more information.

I doubt it.  The fakechroot running the environment hasn't been
updated since it was built, due to the developer's understandable
reluctance to update a key part of the environment.
I've thought about building a later version...have even downloaded the
source...but was holding off until I'd updated a few other things.  It
may be time to take another look.
>
> It may be possible to disable LTO.

Between updating fakechroot and this, this would be the easier option.
Would it be done through configure?
>
> Andrew.
>