On Tue, Dec 15, 2015 at 09:45:29PM +0100, Pierre Labastie wrote:
>
> Actually, we could improve the sanity check after gcc-pass2 to something like:
> ---
> echo 'int main(){}' > dummy.c
> cc -v -Wl,-verbose -lrt dummy.c >& dummy.log
> readelf -l a.out | grep ': /tools'
> grep libpthread dummy.log # should return /tools/lib/libpthread
> # or /mnt/lfs/tools/lib/libpthread
> # maybe a few other "grep"
> ---
> I guess that, if it passes, a lot of common errors have been avoided. It would
> not tell where the error is, but at least it would prevent beginning the build
> with a bad toolchain.
>
> Pierre
>
That sounds useful. I've just been playing with my earlier
suggestion to identify anything linked to the host, but excluding
$LFS_TGT- programs (can't get on with what I really want to do,
because of a minor muscle injury). Unfortunately, I think there
is a bug in (at least) grep-2.21 :
grep $LFS_TGT $P matches when P is e.g. x86_64-lfs-linux-gnu-ar
but fails to match e.g. x86_64-lfs-linux-gnu-elfedit
which caused my subsequent || ldd $P
to report things I did not care about.
For the moment (only caring about x86_64) the following looks as if
it might work -
for P in /tools/bin/[!x86]* ; do
echo $P >>$KM_LOG 2>&1
#grep -q $LFS_TGT $P || ldd $P | grep ' /lib' >>$KM_LOG 2>&1
ldd $P | grep ' /lib' >>$KM_LOG 2>&1 || true
done
for L in /tools/lib/* ; do
echo $L >>$KM_LOG
ldd $L 2>/dev/null | grep ' /lib' >>$KM_LOG 2>&1 || true
done
I am increasingly depressed by playing with this, but I can recall
several times when people have either failed to enter chroot because
of earlier errors, and I think one or two where only one or two
packages were broken, so that they got into chroot but had problems.
After building binutils pass 1 only (I earlier added a
/tools/bin/fubar file for testing) my log shows:
/tools/bin/[!x86]*
/tools/lib/lib
which is not ideal, but perhaps a start.
For the progs, probably
echo $P | grep -q '\!' || echo $P >>$KM_LOG 2>&1
(oh! It seems I have managed to create a spurious symlink:
lfs@jtm1 ~$ ls -l /tools/lib/*
lrwxrwxrwx 1 lfs users 3 Dec 15 23:18 /tools/lib/lib -> lib
Maybe it's just me being a prat, but I think it has come from the
x86_64 case statement. Dunno, I've got the /tools/lib64 -> lib
symlink, never thought to look for /tools/lib/lib before.
ĸ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
