[lfs-dev] Error with check-0.9.9

Pierre Labastie 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'
I get:
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:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib64/librt.so: 
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),
I found:
sys_lib_search_path_spec='/mnt/lfs/tools/lib/gcc/x86_64-lfs-linux-gnu/4.7.2 
/mnt
/lfs/tools/lib/gcc /mnt/lfs/tools/lib64 
/mnt/lfs/tools/x86_64-lfs-linux-gnu/lib '
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 
the book.

Regards
Pierre




More information about the lfs-dev mailing list