>> in this example it seems that the assertion is that no binaries or libraries >> should be linked to >> any host libraries from the second build of binutils >> onwards.
>> Surely, this wouldn't be such a huge addition to the book. Early >> detection of these kinds of problems could smoothen the build process >> and prevent the complexity of trying to figure out what is going wrong >> later in the pipeline. > No, it's not a problem, but be specific with the proper instructions that > are needed and where they need to be placed. 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 >> 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 >That's a bit of overkill. /mnt/lfs/tools/bin at the end of Chapter 5 has >342 entries and /mnt/lfs/tools/lib has 239 entries. Of course, we don't have to include the full listing in writing in the book. But it would be nice to have downloadable scripts available that can make the appropriate checks at the appropriate stages. Also, you didn't answer. Why do we postpone the chroot to chapter 6? Why not chroot as soon as the toolchain is built? Is this not yet possible? Why not? Daer Samej -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
