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 February 11, 2015 5:27:51 AM CST, Andrew Haley <aph@redhat.com> wrote:
>On 02/11/2015 10:00 AM, Cyd Haselton wrote:
>> 
>> 
>> On February 11, 2015 2:36:59 AM CST, Andrew Haley <aph@redhat.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,
>>> 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().
>>>>
>>>> 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.
>
>Andrew.

After a few days of looking at the code and running readelf on various builds of libfakechroot, I don't either...but I have a guess.

The libfakechroot wraps a number of libc commands up in a way that exports a global function named after the libc funct and a local object with the name fakechroot_libcfunction_wrapper.  Example:

bld/fakechrt/fakechroot-2.16 $ readelf -a src/.libs/libfakechroot.so | grep getcwd      94: 000050fc   232 FUNC    GLOBAL DEFAULT    7 getcwd
    53: 00000000     0 FILE    LOCAL  DEFAULT  ABS __getcwd_chk.c
   238: 00000000     0 FILE    LOCAL  DEFAULT  ABS getcwd.c
   553: 000102e8    12 OBJECT  LOCAL  DEFAULT   14 fakechroot_getcwd_wrapper
   672: 000050fc   232 FUNC    GLOBAL DEFAULT    7 getcwd

Somehow these calls are passed  to libc by the wrapper including the dlopen() call...which fails because it should be passed to libdl on android.

How the wrapper points to libc I have no idea.  Why the wrapper around dlopen doesn't pick up 0n the linked libdl.so...again, I have no idea.  Someone with better knowledge of fakechroot internals, symbols and linking will have to tackle this.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


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