[lfs-dev] Error with check-0.9.9
pierre.labastie at neuf.fr
Sun Dec 2 02:31:04 PST 2012
Le 26/11/2012 09:06, Pierre Labastie a écrit :
> First, I confirm that without any flag, everything went well.
Actually not: I had forgotten to remove LDFLAGS=-lpthread from the
configure command, which I had added for testing.
So the error is still there. I think I have found the reason.
After gcc-pass2, using the dummy.c as in the book, try:
gcc -v -Wl,--verbose dummy.c -lrt 2>&1 | grep '\( \|usr\)/lib'
found libpthread.so.0 at /lib/x86_64-linux-gnu/libpthread.so.0
(see 'at /lib/...' instead of 'at /tools/lib/...')
I think people who have a recent enough version of libpthread
on the host won't notice it. But libpthread on Debian is part
of glibc, which is eglibc-2.13, and it seems that
__pthread_get_minstack at GLIBC_PRIVATE has been added later.
That's why I get the error:
undefined reference to `__pthread_get_minstack at GLIBC_PRIVATE'
Note that without the syntax error in putenv.c in the
'check-0.9.9' source, I would not have noticed that either...
I have tried to investigate slightly more:
Looking at ld/config.status in the binutils-build tree (pass2),
sys_lib_dlsearch_path_spec='/lib /usr/lib /usr/lib/atlas
/lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu
/usr/lib/i486-linux-gnu /usr/local/lib /lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu /lib32 /usr/lib32 '
So I think that the search path for libraries is OK, except when a
library is (d)loaded from an another one (libpthread from librt in this
case). However, I browsed the configure script, and it seems that '/lib
/usr/lib' is hardcoded in sys_lib_dlsearch_path_spec. Maybe there is a
way to avoid that, but that I have not found.
Anyway, I think that makes the toolchain not completely independant from
the host and that it is an issue which should be somehow addressed in
More information about the lfs-dev