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: Fri, 6 Feb 2015 10:11:43 -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>
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?
> 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 think.)
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