On Tue, Dec 15, 2015 at 07:00:15PM +0000, Read, James C wrote:
>
> At this stage I can only make suggestions as I don't know enough about the
> correct assertions to make. But what about running this after each build from
> the second pass of binutils onwards to check that no binaries or libraries
> are incorrectly linked to host libraries:
>
> for P in /tools/bin/* ; do echo $P ; ldd $P | grep ' /lib/' ; done
> for P in /tools/lib/* ; do echo $P ; ldd $P | grep ' /lib/' ; done
>
I did say on -support that those were quick suggestions. Your later
posts on -support, and now Chris's confirmation, show that the
${LFS_TGT} programs need to be ignored. Also, those hacks were to
help identify _which_ progs or libs were wrong. The initial tests
can drop the 'echo $P ;' in the expectation that nothing will be
found.
> >> At each stage of the build process perhaps it could be useful to have a
> >> complete listing of which files are expected to be in /tools
>
A maintenance burden - we have enough trouble keeping the chapter 6
contents up to date (ISTR Chris fixed some of those for 7.8).
I'm sure we could mention _something_ like those commands somewhere,
perhaps an initial mention early in chapter 5, and a reminder at the
end of chapter 5. But I think the things that we need to stress
more are checking the prerequisites (in this case, /bin/sh), and
removing the extracted source, and any build directories, after each
program has been installed.
Perhaps we also need to remind people to ensure they have installed
each package before deleting the extracted source and build
directories (anybody building LFS ought to be able to check that with
'ls -l') - from time to time I mistype the prefix when I update my
scripts (/usri is a favourite - you can deduce $EDITOR from that), so
even if I do check that I ran 'make install' that does not confirm it
all worked correctly!
Over the years we have added more things to try to prevent build
failures (particularly, the prerequisites), but only for common
errors. Some of us can create all sorts of really weird build
errors that nobody else is ever likely to encounter (/me holds up
his hand to plead guilty to an environment variable for a scripted
build which conflicted with a shell variable used in a newer
version of a package, and just being careless with CFLAGS).
I have to note that your problem is uncommon - if it was due to
using /bin/dash, or even to reusing old binutils/gcc source or
build directories, a failure first showing up in chapter 5 perl
seems to be new. Good luck with debugging your method, and then
with your build.
ĸ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
