On February 15, 2015 12:57:18 PM CST, Alexander Monakov
wrote:
>
>
>On Sun, 15 Feb 2015, Cyd Haselton wrote:
>
>> On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton
>wrote:
>>
>> *snip*
>> >
>> >> So to obtain the pointer to
>> >> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"),
On Sun, Feb 15, 2015 at 1:14 PM, Alexander Monakov wrote:
>
>
> On Sun, 15 Feb 2015, Cyd Haselton wrote:
>
>> On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov
>> wrote:
>> >> Given that info...and in spite of my aforementioned limited knowledge I
>> >> went back to take another look at the s
On Sun, 15 Feb 2015, Cyd Haselton wrote:
> On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov
> wrote:
> >> Given that info...and in spite of my aforementioned limited knowledge I
> >> went back to take another look at the source and found this in
> >> libfakechroot.c
> >>
> >> /bld/fakechrt
On Sun, 15 Feb 2015, Cyd Haselton wrote:
> On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton wrote:
>
> *snip*
> >
> >> So to obtain the pointer to
> >> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), but not
> >> RTLD_NEXT (the loader precedes the fakeroot library in the lookup
On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton wrote:
*snip*
>
>> So to obtain the pointer to
>> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), but not
>> RTLD_NEXT (the loader precedes the fakeroot library in the lookup chain).
>>
*snip*
Just a quick update: RTLD_DEFAULT is
On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov wrote:
>> Given that info...and in spite of my aforementioned limited knowledge I
>> went back to take another look at the source and found this in
>> libfakechroot.c
>>
>> /bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
>> /
> Given that info...and in spite of my aforementioned limited knowledge I
> went back to take another look at the source and found this in
> libfakechroot.c
>
> /bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
> /* Lazily load function */
> LOCAL fakechroot_wrapperfn_t fakechro
On February 14, 2015 5:08:23 AM CST, Andrew Haley wrote:
>On 13/02/15 22:40, Cyd Haselton wrote:
>> 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
On 13/02/15 22:40, Cyd Haselton wrote:
> 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
On February 11, 2015 5:27:51 AM CST, Andrew Haley wrote:
>On 02/11/2015 10:00 AM, Cyd Haselton wrote:
>>
>>
>> On February 11, 2015 2:36:59 AM CST, Andrew Haley
>wrote:
>>> On 11/02/15 00:41, Cyd Haselton wrote:
>
> I'd rather leave it on-list for future reference. The best thin
On Wed, Feb 11, 2015 at 5:27 AM, Andrew Haley wrote:
> On 02/11/2015 10:00 AM, Cyd Haselton wrote:
>>
>>
>> On February 11, 2015 2:36:59 AM CST, Andrew Haley wrote:
>>> On 11/02/15 00:41, Cyd Haselton wrote:
>
> I'd rather leave it on-list for future reference. The best thing
>
On 02/11/2015 10:00 AM, Cyd Haselton wrote:
>
>
> On February 11, 2015 2:36:59 AM CST, Andrew Haley 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 wa
On February 11, 2015 2:36:59 AM CST, Andrew Haley 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 corr
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 wo
/
>
>>> 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 forwar
On February 6, 2015 10:23:21 AM CST, Andrew Haley wrote:
>On 02/06/2015 04:11 PM, Cyd Haselton wrote:
>> On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley wrote:
>>> On 02/06/2015 11:05 AM, Cyd Haselton wrote:
Technically not a bug, but a limitation of either fakechroot ported
>to Android, Andr
On 02/06/2015 04:11 PM, Cyd Haselton wrote:
> On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley 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.
>
On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley 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
> On Feb 6, 2015, at 5:28 AM, Andrew Haley wrote:
>
> On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote:
>> ...
>> Not sure what's not understood. IIUC you want to disable LTO
>> when building gcc natively on Android? As LTO is considered a
>> "language",
>
> ???
>
> LTO is considered a "lang
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 fro
On February 6, 2015 4:28:01 AM CST, Andrew Haley wrote:
>On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote:
>> On Fri, 6 Feb 2015, Andrew Haley wrote:
>>> On 06/02/15 08:00, Hans-Peter Nilsson wrote:
On Thu, 8 Jan 2015, Andrew Haley wrote:
> Android native GCC can't support LTO because o
On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote:
> On Fri, 6 Feb 2015, Andrew Haley wrote:
>> On 06/02/15 08:00, Hans-Peter Nilsson wrote:
>>> On Thu, 8 Jan 2015, Andrew Haley wrote:
Android native GCC can't support LTO because of a lack of support for
dlopen() in the C library. How sho
On Fri, 6 Feb 2015, Andrew Haley wrote:
> On 06/02/15 08:00, Hans-Peter Nilsson wrote:
> > On Thu, 8 Jan 2015, Andrew Haley wrote:
> >> Android native GCC can't support LTO because of a lack of support for
> >> dlopen() in the C library. How should we patch the configury to disable
> >> LTO by def
On 06/02/15 08:00, Hans-Peter Nilsson wrote:
> On Thu, 8 Jan 2015, Andrew Haley wrote:
>> Android native GCC can't support LTO because of a lack of support for
>> dlopen() in the C library. How should we patch the configury to disable
>> LTO by default?
>
> Doesn't setting unsupported_languages i
On Thu, 8 Jan 2015, Andrew Haley wrote:
> Android native GCC can't support LTO because of a lack of support for
> dlopen() in the C library. How should we patch the configury to disable
> LTO by default?
Doesn't setting unsupported_languages in toplevel configure.ac
work for you?
brgds, H-P
On Fri, Jan 9, 2015 at 6:37 AM, Andrew Haley wrote:
> On 01/09/2015 12:30 PM, Richard Biener wrote:
>> Does --disable-lto-plugin work?
>
> Over to you, Cyd.
>
> Andrew.
>
An additional important note about --disable-lto,
--disable-libsanitizer appears to be required with that option and
bootstrapp
On Fri, Jan 9, 2015 at 6:37 AM, Andrew Haley wrote:
> On 01/09/2015 12:30 PM, Richard Biener wrote:
>> Does --disable-lto-plugin work?
>
> Over to you, Cyd.
>
> Andrew.
>
Yes, it allows the build to continue successfully. Specifically it
allows the libgcc_s.so to be built.
Brief background: the
On 01/09/2015 12:30 PM, Richard Biener wrote:
> Does --disable-lto-plugin work?
Over to you, Cyd.
Andrew.
On Fri, Jan 9, 2015 at 1:16 PM, Andrew Haley wrote:
> On 01/09/2015 10:33 AM, Richard Biener wrote:
>> On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley wrote:
>>> Android native GCC can't support LTO because of a lack of support for
>>> dlopen() in the C library. How should we patch the configury t
On 01/09/2015 10:33 AM, Richard Biener wrote:
> On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley wrote:
>> Android native GCC can't support LTO because of a lack of support for
>> dlopen() in the C library. How should we patch the configury to disable
>> LTO by default?
>
> How does LTO need dlope
On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley wrote:
> Android native GCC can't support LTO because of a lack of support for
> dlopen() in the C library. How should we patch the configury to disable
> LTO by default?
How does LTO need dlopen? It seems it only cannot use the linker plugin
in whi
Android native GCC can't support LTO because of a lack of support for
dlopen() in the C library. How should we patch the configury to disable
LTO by default?
Thanks,
Andrew.
32 matches
Mail list logo