This is the mail archive of the
mailing list for the GCC project.
Re: Android native build of GCC
- From: Cyd Haselton <chaselton at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Hans-Peter Nilsson <hp at bitrange dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 11 Feb 2015 06:08:47 -0600
- Subject: Re: Android native build of GCC
- Authentication-results: sourceware.org; auth=none
- References: <54AE581C dot 5070003 at redhat dot com> <alpine dot BSF dot 2 dot 02 dot 1502060258210 dot 10842 at arjuna dot pair dot com> <54D48673 dot 9070901 at redhat dot com> <alpine dot BSF dot 2 dot 02 dot 1502060458370 dot 29537 at arjuna dot pair dot com> <54D49731 dot 7030407 at redhat dot com> <F47323AC-2C7B-47B8-B630-D03A629DD347 at gmail dot com> <54D4A6C2 dot 1040808 at redhat dot com> <CAHu5Prbo2J1p2ueC3G5A6r-ZUo0z6JG1X_9OmshEyKPjjh0hTQ at mail dot gmail dot com> <54D4EA79 dot 10909 at redhat dot com> <6A2D97AB-19B8-4A78-ABE7-B486D1C41FCC at gmail dot com> <54DB14AB dot 3040501 at redhat dot com> <87A6FCF6-9A36-43DE-9981-6663EF51D81F at gmail dot com> <54DB3CB7 dot 1040108 at redhat dot com>
On Wed, Feb 11, 2015 at 5:27 AM, Andrew Haley <firstname.lastname@example.org> wrote:
> On 02/11/2015 10:00 AM, Cyd Haselton wrote:
>> On February 11, 2015 2:36:59 AM CST, Andrew Haley <email@example.com> wrote:
>>> On 11/02/15 00:41, Cyd Haselton wrote:
>>>>> I'd rather leave it on-list for future reference. The best thing
>>>>> would be for libfakechroot to be linked against libdl: that way,
>>>>> dlopen() was called the link would be correctly satisfied. If that
>>>>> isn't possible (if dlopen() doesn't work or is incompatible) then
>>>>> libfakechroot shouldn't export the symbol for dlopen().
>>>> After experimenting with several builds of the fakechroot library I
>>>> can't see how this would be possible. Even when libdl is linked in,
>>>> hiding dlopen guarantees that the resulting library doesn't
>>>> intercept dlopen calls, which breaks the fakechroot environment and
>>>> removing the fakechroot dlopen code also ensures that dlopen calls
>>>> aren't intercepted.
>>> I don't get it. If libdl is linked in, why would you hide dlopen() ?
>> libdl was linked in the original, buggy libfakechroot...the one that exported dlopen().
> But if it was linked in, where did the dlopen() link error come from? It
> should have succeeded because dlopen() should have been found in libdl.
> I still don't get it.
Neither do I...hence my confusion. Even more so because neither this
nor Linux are systems I usually work with.
I have an idea of what may be the problem, but it's just a guess,
given my rudimentary understanding of how the linker, shared and
dynamic libraries work.
The original libfakechroot was cross-compiled to link against the
system libc, and not the system libdl....hence libdl not being found.
The experiments I did with libfakechroot linked the sysroot libdl and
not the system libdl, therefore all dlopen() calls went straight to
the system libdl, bypassing the fakechroot environment.
Does that sound plausible?