Re: Android native build of GCC
On February 14, 2015 5:08:23 AM CST, Andrew Haley a...@redhat.com 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 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.
Ah, I think I might know. When you call dlsym() you have the option
of passing a handle to the library you want to search. Usually
dlsym() searches all loaded libraries, but it's possible that
libfakechroot specifies that only libc is searched.
Andrew.
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 fakechroot_loadfunc (struct fakechroot_wrapper * w)
{
char *msg;
if (!(w-nextfunc = dlsym(RTLD_NEXT, w-name))) {;
msg = dlerror();
fprintf(stderr, %s: %s: %s\n, PACKAGE, w-name, msg != NULL ? msg :
unresolved symbol);
exit(EXIT_FAILURE);
}
I'm fairly certain I remember reading something about Android and lazy function
loadinghow it doesn't handle it well or does so differently from standard
Linux builds. At any rate, I believe the above code is responsible for those
annoying 'fakechroot: undefined reference to dlopen' errors, so I'll see if I
can fix that.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
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 fakechroot_loadfunc (struct fakechroot_wrapper *
w)
{
char *msg;
if (!(w-nextfunc = dlsym(RTLD_NEXT, w-name))) {;
msg = dlerror();
fprintf(stderr, %s: %s: %s\n, PACKAGE, w-name, msg != NULL ? msg :
unresolved symbol);
exit(EXIT_FAILURE);
}
I'm fairly certain I remember reading something about Android and lazy
function loadinghow it doesn't handle it well or does so differently
from standard Linux builds. At any rate, I believe the above code is
responsible for those annoying 'fakechroot: undefined reference to dlopen'
errors, so I'll see if I can fix that.
In Android's Bionic libc, the implementation of dlopen() resides in the
dynamic loader, and not present in libdl.so. 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).
The preceding discussion seems to have libc and libdl switched. Normally the
implementation of dlopen is found in libdl.so, but not in libc.so.
Hope that helps,
Alexander
Re: Android native build of GCC
On Sun, 15 Feb 2015, Cyd Haselton wrote:
On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov amona...@ispras.ru
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
/* Lazily load function */
LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct
fakechroot_wrapper * w)
{
char *msg;
if (!(w-nextfunc = dlsym(RTLD_NEXT, w-name))) {;
msg = dlerror();
fprintf(stderr, %s: %s: %s\n, PACKAGE, w-name, msg != NULL ?
msg : unresolved symbol);
exit(EXIT_FAILURE);
}
I'm fairly certain I remember reading something about Android and lazy
function loadinghow it doesn't handle it well or does so differently
from standard Linux builds. At any rate, I believe the above code is
responsible for those annoying 'fakechroot: undefined reference to dlopen'
errors, so I'll see if I can fix that.
In Android's Bionic libc, the implementation of dlopen() resides in the
dynamic loader, and not present in libdl.so.
Yet in Android's NDK documentation, they state that in order to use
dlopen() functionality in native code you must link against libdl and
include dlfcn.h. Why would this be the case if the dlopen()
implementation is not in libdl?
(documentation link: http://www.kandroid.org/ndk/docs/STABLE-APIS.html)
That's the standard way of using dlopen, i.e. same as you would do it on Linux
with glibc for example. So the link merely says that you can get dlopen the
same way as usual.
The difference is that Android's libdl only contains stub symbols for
dlopenco, and the real symbols can be looked up in the dynamic loader. That
RTLD_NEXT does not work for obtaining a pointer for dlopen, as it works on
glibc, is quite unfortunate, and probably a bug in Bionic.
Alexander
Re: Android native build of GCC
On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov amona...@ispras.ru 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
/* Lazily load function */
LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct fakechroot_wrapper
* w)
{
char *msg;
if (!(w-nextfunc = dlsym(RTLD_NEXT, w-name))) {;
msg = dlerror();
fprintf(stderr, %s: %s: %s\n, PACKAGE, w-name, msg != NULL ? msg
: unresolved symbol);
exit(EXIT_FAILURE);
}
I'm fairly certain I remember reading something about Android and lazy
function loadinghow it doesn't handle it well or does so differently
from standard Linux builds. At any rate, I believe the above code is
responsible for those annoying 'fakechroot: undefined reference to dlopen'
errors, so I'll see if I can fix that.
In Android's Bionic libc, the implementation of dlopen() resides in the
dynamic loader, and not present in libdl.so.
Yet in Android's NDK documentation, they state that in order to use
dlopen() functionality in native code you must link against libdl and
include dlfcn.h. Why would this be the case if the dlopen()
implementation is not in libdl?
(documentation link: http://www.kandroid.org/ndk/docs/STABLE-APIS.html)
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).
The preceding discussion seems to have libc and libdl switched. Normally the
implementation of dlopen is found in libdl.so, but not in libc.so.
So in standard Linux builds, libc.so doesn't contain the dlopen()
implementation...as in Android?
Hope that helps,
Alexander
It saves me a lot of time poring through reams of speculation,
verbiage and complicated example code about Android's sparse
documentation so, thanks.
Re: Android native build of GCC
On Sun, 15 Feb 2015, Cyd Haselton wrote: On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton chasel...@gmail.com 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 definitely not the solution here as it results in a segfault when libfakechroot loads. Perhaps a different RTLD_FLAG was meant? I think you need to use RTLD_DEFAULT only when resolving dlopen, and keep RTLD_NEXT for all other symbol names (unless later on you run into other symbols with similar behavior). Something like ... = dlsym(strcmp(name, dlopen) ? RTLD_NEXT : RTLD_DEFAULT, name); Alexander
Re: Android native build of GCC
On Sun, Feb 15, 2015 at 1:14 PM, Alexander Monakov amona...@ispras.ru wrote:
On Sun, 15 Feb 2015, Cyd Haselton wrote:
On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov amona...@ispras.ru
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
/* Lazily load function */
LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct
fakechroot_wrapper * w)
{
char *msg;
if (!(w-nextfunc = dlsym(RTLD_NEXT, w-name))) {;
msg = dlerror();
fprintf(stderr, %s: %s: %s\n, PACKAGE, w-name, msg != NULL ?
msg : unresolved symbol);
exit(EXIT_FAILURE);
}
I'm fairly certain I remember reading something about Android and lazy
function loadinghow it doesn't handle it well or does so differently
from standard Linux builds. At any rate, I believe the above code is
responsible for those annoying 'fakechroot: undefined reference to dlopen'
errors, so I'll see if I can fix that.
In Android's Bionic libc, the implementation of dlopen() resides in the
dynamic loader, and not present in libdl.so.
Yet in Android's NDK documentation, they state that in order to use
dlopen() functionality in native code you must link against libdl and
include dlfcn.h. Why would this be the case if the dlopen()
implementation is not in libdl?
(documentation link: http://www.kandroid.org/ndk/docs/STABLE-APIS.html)
That's the standard way of using dlopen, i.e. same as you would do it on Linux
with glibc for example. So the link merely says that you can get dlopen the
same way as usual.
The difference is that Android's libdl only contains stub symbols for
dlopenco, and the real symbols can be looked up in the dynamic loader. That
RTLD_NEXT does not work for obtaining a pointer for dlopen, as it works on
glibc, is quite unfortunate, and probably a bug in Bionic.
Alexander
Would it have anything to do with Android's symbol searching method?
I.e. a library must be explicitly linked and loaded if needed; on load
a library won't look to already loaded libraries to resolve symbols?
Re: Android native build of GCC
On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton chasel...@gmail.com 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 definitely not the solution here as it results in a segfault when libfakechroot loads. Perhaps a different RTLD_FLAG was meant?
Re: Android native build of GCC
On February 15, 2015 12:57:18 PM CST, Alexander Monakov amona...@ispras.ru wrote: On Sun, 15 Feb 2015, Cyd Haselton wrote: On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton chasel...@gmail.com 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 definitely not the solution here as it results in a segfault when libfakechroot loads. Perhaps a different RTLD_FLAG was meant? I think you need to use RTLD_DEFAULT only when resolving dlopen, and keep RTLD_NEXT for all other symbol names (unless later on you run into other symbols with similar behavior). Something like ... = dlsym(strcmp(name, dlopen) ? RTLD_NEXT : RTLD_DEFAULT, name); Alexander I believe that worked perfectly; compiling Python no longer causes fakechroot to throw an undefined reference to dlopen(). Many, many thanks. For my future reference, are there recommended references/documentation for Android's linker in particular and dynamic linking, shared/static libraries, and symbol resolution in general...other than man dlopen/dlsym/etc? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
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 linked libdl.so...again, I have no idea. Someone with better knowledge of fakechroot internals, symbols and linking will have to tackle this. Ah, I think I might know. When you call dlsym() you have the option of passing a handle to the library you want to search. Usually dlsym() searches all loaded libraries, but it's possible that libfakechroot specifies that only libc is searched. Andrew.
Re: Android native build of GCC
On February 11, 2015 5:27:51 AM CST, Andrew Haley a...@redhat.com wrote: On 02/11/2015 10:00 AM, Cyd Haselton wrote: On February 11, 2015 2:36:59 AM CST, Andrew Haley a...@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: 50fc 232 FUNCGLOBAL DEFAULT7 getcwd 53: 0 FILELOCAL DEFAULT ABS __getcwd_chk.c 238: 0 FILELOCAL DEFAULT ABS getcwd.c 553: 000102e812 OBJECT LOCAL DEFAULT 14 fakechroot_getcwd_wrapper 672: 50fc 232 FUNCGLOBAL DEFAULT7 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.
Re: Android native build of GCC
On February 11, 2015 2:36:59 AM CST, Andrew Haley a...@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() ? Andrew. libdl was linked in the original, buggy libfakechroot...the one that exported dlopen(). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
On Wed, Feb 11, 2015 at 5:27 AM, Andrew Haley a...@redhat.com wrote: On 02/11/2015 10:00 AM, Cyd Haselton wrote: On February 11, 2015 2:36:59 AM CST, Andrew Haley a...@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. Neither do I...hence my confusion. Even more so because neither this nor Linux are systems I usually work with. I have an idea of what may be the problem, but it's just a guess, given my rudimentary understanding of how the linker, shared and dynamic libraries work. The original libfakechroot was cross-compiled to link against the system libc, and not the system libdlhence libdl not being found. The experiments I did with libfakechroot linked the sysroot libdl and not the system libdl, therefore all dlopen() calls went straight to the system libdl, bypassing the fakechroot environment. Does that sound plausible? Cyd
Re: Android native build of GCC
On 02/11/2015 10:00 AM, Cyd Haselton wrote: On February 11, 2015 2:36:59 AM CST, Andrew Haley a...@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.
Re: Android native build of GCC
/ 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. 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. Cyd -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
On February 6, 2015 10:23:21 AM CST, Andrew Haley a...@redhat.com wrote: On 02/06/2015 04:11 PM, Cyd Haselton wrote: On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley a...@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(). I;ve contacted the developer of KBOX and download sources. If possible, I'll build a corrected version and replace the existing. Andrew. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
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
Re: Android native build of GCC
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 default? Doesn't setting unsupported_languages in toplevel configure.ac work for you? I'm sorry, I don't understand this comment. Not sure what's not understood. IIUC you want to disable LTO when building gcc natively on Android? As LTO is considered a language, disabling it by means of the support for targets or hosts to disable languages (by setting the shell variable unsupported_languages) seemed to make sense...though looking closer, I see the language configury is slightly fudged and needs some code moving to fix that, as e.g. lto-plugin conditionals and special lto handling have snuck in before the unsupported_languages processing. Bah. Never mind. brgds, H-P
Re: Android native build of GCC
On February 6, 2015 4:28:01 AM CST, Andrew Haley a...@redhat.com 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 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? I'm sorry, I don't understand this comment. 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 language? Who knew? disabling it by means of the support for targets or hosts to disable languages (by setting the shell variable unsupported_languages) seemed to make sense...though looking closer, I see the language configury is slightly fudged and needs some code moving to fix that, as e.g. lto-plugin conditionals and special lto handling have snuck in before the unsupported_languages processing. Bah. Never mind. :-) Anyway, it turns out that only the LTO plugin should be disabled, and it turned out that was due to a bug in the weird shim library being used to do native Android builds. So I guess we're OK. Andrew. Technically not a bug, but a limitation of either fakechroot ported to Android, Android's severely stripped libc, or a combination of the two. At any rate, the Android GCC 4.9.2 build has been used to compile a number of other programs on device...so yeah, we're ok. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
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 in toplevel configure.ac work for you? I'm sorry, I don't understand this comment. Andrew.
Re: Android native build of GCC
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 should we patch the configury to disable LTO by default? Doesn't setting unsupported_languages in toplevel configure.ac work for you? I'm sorry, I don't understand this comment. 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 language? Who knew? disabling it by means of the support for targets or hosts to disable languages (by setting the shell variable unsupported_languages) seemed to make sense...though looking closer, I see the language configury is slightly fudged and needs some code moving to fix that, as e.g. lto-plugin conditionals and special lto handling have snuck in before the unsupported_languages processing. Bah. Never mind. :-) Anyway, it turns out that only the LTO plugin should be disabled, and it turned out that was due to a bug in the weird shim library being used to do native Android builds. So I guess we're OK. Andrew.
Re: Android native build of GCC
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(). 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.) Andrew.
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 a...@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.
Re: Android native build of GCC
On Feb 6, 2015, at 5:28 AM, Andrew Haley a...@redhat.com 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 language? Who knew? It would be nice if ./configure --help told us what the value arguments to --enable-languages are. paul
Re: Android native build of GCC
On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley a...@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? 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. Andrew.
Re: Android native build of GCC
On Fri, Jan 9, 2015 at 6:37 AM, Andrew Haley a...@redhat.com 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 bootstrapping doesn't appear to work. For the record, the complete configure I used for the build: ../gcc-4.9.2/configure --prefix=/usr/gcc-4.9.2 --build=arm-linux-androideabi --host=arm-linux-androideabi --target=arm-linux-androideabi --disable-ld --with-mpfr=/usr/gcc-4.9.2 --with-mpc=/usr/gcc-4.9.2 --with-gmp=/usr/gcc-4.9.2 --with-as=/usr/gcc-4.9.2/bin/as --with-ld=/usr/gcc-4.9.2/bin/ld --enable-shared --enable-languages=c,c++ --disable-bootstrap --disable-sjlj-exceptions --disable-nls --disable-gold --disable-fortran --disable-libssp --disable-lto --disable-libquadmath --disable-libquadmath-support --disable-libada --disable-werror --disable-multilib --disable-libgomp --disable-cloog --with-build-time-tools=/usr/gcc-4.8.3/bin CFLAGS=-Wall -O2 -mandroid -mbionic CXXFLAGS=-Wall -mandroid -mbionic -frtti LDFLAGS=-Wl,--dynamic-linker=/system/bin/linker -lc -ldl -lgcc -lm LIBCFLAGS=-O2 -mandroid -mbionic LIBCPPFLAGS=-O2 -mandroid -mbionic LIBCXXFLAGS=-O2 -mandroid -mbionic -fno-implicit-templates -frtti LIBS=-lc -ldl -lgcc -lm -lsupc++ -lgnustl_shared --with-build-sysroot=/usr/gcc-4.8.3/sysroot --disable-libsanitizer
Re: Android native build of GCC
On Fri, Jan 9, 2015 at 6:37 AM, Andrew Haley a...@redhat.com 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 fakechroot lib is specific to the environment I'm using on Android to build GCC; it simulates a Linux-style filesystem making it easier to port various utilities and programs.
Re: Android native build of GCC
On 01/09/2015 10:33 AM, Richard Biener wrote: On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley a...@redhat.com 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 That's right, it's the plugin which is causing the problem. in which case the existing check for plugin-supporting ld should catch it? It doesn't seem to. The problem is probably caused by libfakechroot.so, which intercepts calls to dlopen() and tries to forward them. Unfortunately dlopen() is not in Android's libc, so libfakechroot returns a link error for dlopen(). I don't know what the check for plugin-supporting ld does, but I guess it doesn't call dlopen(). I'll grant you that this isn't really our bug: libfakechroot shouldn't be exporting dlopen() on Android. Andrew.
Re: Android native build of GCC
On Fri, Jan 9, 2015 at 1:16 PM, Andrew Haley a...@redhat.com wrote: On 01/09/2015 10:33 AM, Richard Biener wrote: On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley a...@redhat.com 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 That's right, it's the plugin which is causing the problem. Building it, I suppose? Does --disable-lto-plugin work? Richard. in which case the existing check for plugin-supporting ld should catch it? It doesn't seem to. The problem is probably caused by libfakechroot.so, which intercepts calls to dlopen() and tries to forward them. Unfortunately dlopen() is not in Android's libc, so libfakechroot returns a link error for dlopen(). I don't know what the check for plugin-supporting ld does, but I guess it doesn't call dlopen(). I'll grant you that this isn't really our bug: libfakechroot shouldn't be exporting dlopen() on Android. Andrew.
Re: Android native build of GCC
On 01/09/2015 12:30 PM, Richard Biener wrote: Does --disable-lto-plugin work? Over to you, Cyd. Andrew.
Re: Android native build of GCC
On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley a...@redhat.com 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 which case the existing check for plugin-supporting ld should catch it? Richard. Thanks, Andrew.
Android native build of GCC
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.
