This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Android native build of GCC


On 02/06/2015 04:11 PM, Cyd Haselton wrote:
> On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley <aph@redhat.com> 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
>> 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
> reply.

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().

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]