On Wed, Dec 16, 2015 at 12:24:04AM +0000, Ken Moffat wrote:
> On Tue, Dec 15, 2015 at 09:45:29PM +0100, Pierre Labastie wrote:
>
> (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.
>
Possibly, it got generated when I interrupted a build, although I
cannot see why. On a rerun starting with an empty /tools I cannot
persuade it to reappear, so disregard that.
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)
# run ldd on any progs and libs in /tools, looking for host /lib
TOOLS_HOSTPROGS=0
for P in /tools/bin/[!x86]* ; do
echo $P | grep -q '\!' || ldd $P | grep -q ' /lib' &&
TOOLS_HOSTPROGS=1 || true
done
test $TOOLS_HOSTPROGS -eq 0 &&
echo "no progs linked to host libs" ||
for P in /tools/bin/[!x86]* ; do
echo $P | grep -q '\!' || echo $P >>$KM_LOG 2>&1
ldd $P | grep ' /lib' >>$KM_LOG 2>&1 || true
done
TOOLS_HOSTLIBS=0
for L in /tools/lib/lib* ; do
# for static libs, ldd warns about a lack of execute permission
ldd $L 2>/dev/null | grep ' /lib' &&
TOOLS_HOSTLIBS=1 || true
done
test $TOOLS_HOSTLIBS -eq 0 && echo "no libs linked to host libs" ||
for L in /tools/lib/lib* ; do
echo $L >>$KM_LOG
ldd $L 2>/dev/null | grep ' /lib' >>$KM_LOG 2>&1 || true
done
When I tested this on pass 1 gcc I did not catch the name of the
first library, so I guess it is still a bit buggy.
I've now interrupted the build at bzip2, and manually built and
installed that without PATH or LFS_TGT being correct. When I run
the above commands, with logging, I get a list of all the progs in
/tools, with details of those linked to the host, e.g.
[...]
/tools/bin/bash
/tools/bin/bashbug
/tools/bin/bunzip2
libc.so.6 => /lib/libc.so.6 (0x00007f1ab919c000)
/tools/bin/bzcat
libc.so.6 => /lib/libc.so.6 (0x00007fb2849ab000)
/tools/bin/bzcmp
/tools/bin/bzdiff
/tools/bin/bzegrep
/tools/bin/bzfgrep
/tools/bin/bzgrep
/tools/bin/bzip2
libc.so.6 => /lib/libc.so.6 (0x00007f302e5a2000)
/tools/bin/bzip2recover
libc.so.6 => /lib/libc.so.6 (0x00007fa8da9fc000)
/tools/bin/bzless
/tools/bin/bzmore
/tools/bin/c++
[...]
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.
If I'm doing this again, I suppose I'd better stop the correct build
at ncurses, and then build that without the variables set, to get
some bad libs. But before I waste time on that (I've now got a lot
of systems which ought to be updated for firefox-43), is it worth
doing ?
Also, if we do offer a script, we could start by testing for the
horrible /bin/dash. There is no way I can be persuaded to install
that, but after doing a build I see that it does not respect
--version, so we could begin with:
/bin/sh --version >/dev/null 2>&1 ||
echo "ERROR: read the Host System Requirements for /bin/sh"
Opinions ?
If we want to do this, my current feeling is that we should first
mention it at the end of glibc in chapter 5, and then again (perhaps
as a new section) after xz in chapter 5.
ĸ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
