On Wed, Dec 16, 2015 at 04:48:48AM +0000, Ken Moffat wrote:
>
> For linking to host files, it looks like gcc pass 1 has some libs
> linked to the host. If I start testing after glibc has been
> installed, the following seems to work on a good build on x86_64
> (and this time I'll strip out the logging)
>
[ snipped, I gotta newer version ]
>
> I suppose it would be better to just run the grep, but silently, and
> only report the programs and/or libraries that happen to be bad,
> without specifying which host libs they link to - even at this stage
> there are a lot of programs.
>
Here be dragons!
Ran my normal build up to gcc pass 2, then tried manually building
tcl without the correct environment.
I've now got a script, tools-check.sh:
- - -
#!/bin/sh
# first check that /bin/sh is not dash
/bin/sh --version >/dev/null
if [ $? -ne 0 ]; then
echo "ERROR: read the Host System Requirements for /bin/sh"
exit 1
fi
# check the programs, except any -lfs- progs from pass 1
PROGS=$(ls /tools/bin/* | sed -e 's/.*-lfs-.*//' -e '/^$/d' )
TOOLS_HOSTPROGS=n
for P in $PROGS ; do
ldd $P | grep -q ' /lib' && echo "$P is linked to /lib" &&
TOOLS_HOSTPROGS=y
ldd $P | grep -q ' /usr/lib' && echo "$P is linked to /usr/lib" &&
TOOLS_HOSTPROGS=y
done
TOOLS_HOSTLIBS=0
# ldd warns about lack of execute perm
for L in /tools/lib/lib*.so ; do
ldd $L 2>/dev/null | grep -q ' /lib' &&
echo "$L is linked to /lib" && TOOLS_HOSTLIBS=y
ldd $L 2>/dev/null | grep -q ' /usr/lib' &&
echo "$L is linked to /usr/lib" && TOOLS_HOSTLIBS=y
done
if [ $TOOLS_HOSTPROGS = "y" ] || [ $TOOLS_HOSTLIBS = "y" ]; then
echo 'ERROR'
exit 1
fi
- - -
The observant will notice that I remembered that sometimes people
have linked things to /usr (e.g. incorrect builds of grep). For
programs, this seems to be doing the right thing [ NOT tested with
anything linked to /usr at this point ], i.e. it tells me
/tools/bin/tclsh is linked to /lib
/tools/bin/tclsh8.6 is linked to /lib
But for the libraries, I just got pain. As well as the tcl libs
linked to /lib, I discovered that *many* libraries from glibc, and
also libstdc++, are linked to /lib, and a couple are also linked to
/usr (libgcc_s : we handle that one when we enter chroot.
The affected libraries are libanl, libatomic, libBrokenLocale{-2.22,},
libcidn{-2.22,}, libcrypt{-2.22,}, libdl{-2.22,}, libgcc_s, libitm,
libm-2.22, libmemusage, libmvec{-2.22,}, libnsl{-2.22,},
libnss_compat{-2.22,}, libnss_db{-2.22,}, libnss_dns{-2.22,},
libnss_files{-2.22,}, libnss_hesiod{-2.22,}, libnss_nis{-2.22,},
libnss_nisplus{-2.22,}, libpcprofile, libquadmath, libresol{-2.22,},
librt{-2.22}, libSegFault, libssp, libstdc++, libthread_db{-1.0,},
libutil{-2.22,}, libvtv.
There are so many special cases here, I don't think that a script
would be maintainable. At this point, I have one broken lib
(libtcl8.6.so) and in that particular example, what links to /lib is
libz. On a box with unified /usr, I guess that would link to
/usr/lib/libz. For /tools/bin/tclsh the situation is similar, and
they both correctly link to /tools/lib/libc.so.6.
Now, I can see that I could start to ignore libraries which link to
/lib/libc.so and also /lib/libpthread.so, libdl.so, libm.so (the
toolchain as far as libmved, at that point I gave up), even though I
would really want to check libc on all the other packages to confirm
isolation from the host, but this whole idea starts to look terribly
fragile.
I suspect that it would end up like the testsuites from some upstream
packages - it could catch many of the known errors (if people are
willing to describe what they did wrong), but people will still
manage to break things in new ways. Therefore it would NOT give
strong confidence that a build was ok, so it does not seem worth the
likely ongoing maintenance burden.
Oh, and on 32-bit, ld-linux will also show up - on x86_64 it is in
/lib64 so doesn't appear in my results.
ĸen
--
This email was written using 100% recycled letters.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
