This is the mail archive of the
gcc@gcc.gnu.org
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: Wed, 11 Feb 2015 08:36:59 +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> <54D4EA79 dot 10909 at redhat dot com> <6A2D97AB-19B8-4A78-ABE7-B486D1C41FCC at gmail dot com>
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() ?
Andrew.