Hi,
Not long ago, I had some problems with the building of check, which
I traced back to some problem with binutils pass2 (see
http://linuxfromscratch.org/pipermail/lfs-dev/2012-December/067444.html).
But it seemed that nobody had the same issue.
I think I have found the way to trigger the bug:
---------------------------------------------------------------
On the host, become root and create an empty <library> directory
(say /opt/dummy/lib). Add that directory to ld.so.conf:
cp /etc/{ld.so.conf,.orig}
cat >> /etc/ld.so.conf << EOF
/opt/dummy/lib
EOF
Copy the libpthread libraries to the <library> dir (their initial
location may
vary):
cp /lib/libpthread* /opt/dummy/lib
then become lfs and start lfs using the current book up to gcc pass 2.
Or if you use jhalfs, type:
make
Do whatever configuration you want but untick "run makefile".
Then change dir to $LFS/jhalfs and type:
make BREAKPOINT=037-gcc-pass2
At this point, if you are not already the lfs user, you have to su to lfs.
Do not forget to source .bashrc if you have used jhalfs.
then type:
echo main'(){}' | gcc -xc -v -Wl,-verbose - -lrt |& grep '/opt'
The result will be, I think:
found libpthread.so.0 at /opt/dummy/lib/libpthread.so.0
Do not forget to erase /opt/dummy/lib and to copy back
ld.so.conf.orig
-------------------
COMMENTS:
- The reason why this bug shows up on Debian is that they now put the
system libraries in /lib/x86_64-linux-gnu, which they must have in
ld.so.conf. On other systems, it is not likely that libpthread
is in a directory which is also in /etc/ld.so.conf
- It seems to me that it is something to worry about, because it creates
a potential pollution of the toolchain by host libraries.
-------------------
ANALYSIS:
When you give the flag -lrt, ld pulls up correctly /tools/lib/librt.so. But
that library needs libpthread, and for some reason, ld does not have the
same search algorithm for dso linked from another dso: see the
description under the flag -rpath-link in 'man ld'.
The main conclusion is that for a native linker, and if the sysroot
capability has not been compiled in, ld does not use the rpath of
the dso, but reads ld.so.conf to know where to search libraries
needed by other shared libraries. If that fails, then it looks for
it in the lib-path given at compilation time.
Just compiling the sysroot capability (ie adding --with-sysroot
to configure options in binutils pass 2) is enough to change
that behavior. I have made several complete builds with
that flag with no problems (not done an ICA though).
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
