This is the mail archive of the
mailing list for the GCC project.
Re: Android native build of GCC
- From: Andrew Haley <aph at redhat dot com>
- To: Cyd Haselton <chaselton at gmail 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: Fri, 06 Feb 2015 16:23:21 +0000
- 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>
On 02/06/2015 04:11 PM, Cyd Haselton wrote:
> On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley <firstname.lastname@example.org> wrote:
>> On 02/06/2015 11:05 AM, Cyd Haselton wrote:
>>> Technically not a bug, but a limitation of either fakechroot ported to Android, Android's severely stripped libc, or a combination of the two.
>> I think it's a bug. libfakechroot presents a version of dlopen() on
>> the assumption that the libc it's fronting has dlopen().
> Wouldn't the ported version of libfakechroot do otherwise...i.e. take
> into account that dlopen() does not reside in bionic?
I have no idea. I would hope so.
>> So, anyone probing for dlopen() finds it in libfakechroot.
>> However, when that dlopen() is called you get a (very confusing)
>> link error. This is a bug because if the underlying C library does
>> not have dlopen() then libfakechroot should either not export it or
>> should forward calls to the right library (which was libdl.so, I
> Out of curiosity (and future libfakechroot porting purposes) how would
> this look? I know that this and the previous question are off -topic
> to the original email so feel free to leave the list out of your
I'd rather leave it on-list for future reference. The best thing
would be for libfakechroot to be linked against libdl: that way, when
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().