Hi there,
In the cross-lfs book, chapter 5, we build gcc shared to create a libgcc_s.so. But there can be a small purity-issue: the dirs this new gcc searches for programs/libraries still contain a dir on the host. In my case /usr/lib/i686-pc-linux-gnu/3.4.3.
This can be a problem if the gcc on your host has libgcc_s.so in this dir. That can be the case if your host-gcc has been build with --enable-version-specific-runtime-libs, (or if you have been playing with crosscompiling too much :)))
Here you can see it: using a host with libgcc_s.so in /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/
echo 'main(){}' > /tmp/dummy.c
i686-pc-linux-gnu-gcc -Wl,--verbose /tmp/dummy.c 2>&1 |grep libgcc_s.soThis is the output:
attempt to open /home/lfs/cross-tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so failed
attempt to open /home/lfs/cross-tools/bin/../lib/gcc/libgcc_s.so failed
attempt to open /cross-tools/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so failed
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so succeeded
/libgcc_s.so)
With a "normal" host, libgcc_s.so in /usr/lib, the output is:
attempt to open /home/lfs/cross-tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so failed
attempt to open /home/lfs/cross-tools/bin/../lib/gcc/libgcc_s.so failed
attempt to open /cross-tools/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so failed
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so failed
attempt to open /home/lfs/cross-tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/lib/libgcc_s.so succeeded
-lgcc_s (/home/lfs/cross-tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/lib/libgcc_s.so)
As you can see, in the first case it uses libgcc_s.so from the host, in the second case it uses the newly build libgcc_s.so.
Now my questions:
Can this do any harm? I don't know if libgcc_s actually gets used, but it doesn't look good for purity's sake.
If so, should we do something about it? It is something most normal users won't see, because they have their libgcc_s in /usr/lib.
If so, what should we do about it? There are a few possibilities:
- Put cross-tools libgcc_s in a dir where it will be picked up first: cp /cross-tools/i686-pc-linux-gnu/lib/libgcc_s.so \ /cross-tools/lib/gcc/i686-pc-linux-gnu/3.4.3/
- same as above, but make symlinks instead of copy
- configure shared gcc with --enable-version-specific-runtime-libs so libgcc_s.so gets installed in /cross-tools/lib/gcc/i686-pc-linux-gnu/3.4.3/ instead of in /cross-tools/i686-pc-linux-gnu/lib/
- configure shared gcc with --with-slibdir=/cross-tools/lib/gcc/i686-pc-linux-gnu/3.4.3/
- sed/patch the source (gcc/gcc.c) so the hard-codes /usr/lib gets replaced by /tools/lib:
sed -i "/standard_exec_prefix_/s%/usr%/tools%g" gcc/gcc.c
My preference would be the sed/patch, because it removes all the hardcoded host-dirs from gcc's search-path.
Bye Erik-Jan
PS to see gcc's searchpaths in a better readable way: i686-pc-linux-gnu-gcc -print-search-dirs | sed "s%:%\n%g"
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
