On Sat, Mar 27, 2021 at 11:00:06PM +0100, Patrick Frisch wrote: > Hello again, > > now I completed the lfs build, and I had a very nasty problem with your > handling of /lib64 and the new approach, that the toolchain is no longer > isolated in /tools. > > After solving my problem in the previous discussion, I started my packaging > at the beginning of Chapter 7 now by package everything in $LFS at the end > of Chapter 6 to an initial package. > > So everything works well, the libs and programs in $LFS are rebuild in > Chapters 7 and 8 and are captured by my packaging method correctly. So, in > theory, after completing Chapter 8, I don't need anything from my initial > toolchain package, so I should be able to remove it from my package chain. > > But by removing it, i render my new system unusable, since /lib64 is created > in the toolchain phase in Chapter 5.5.1 only and is never touched again in > any following package. So by removing my initial toolchain package I remove > /lib64 and the very important link in it. >
You do realise that the LFS book is written for building on the system where it will be used ? At the end of LFS your system should be bootable if you follow the book. Removing files which the book does not remove can be a learning experience. In my own case, when I decide to make a static lib unavailable I rename it so it will not be found, but can be made available when needed, e.g. /usr/lib/libstdc++.a.hidden (needed for anything using gn, which in BLFS is only qtwebengine). Any package management system implies that you may need to alter what the books do, e.g. if you are building for multiple systems you might need to alter the instructions for packages such as gmp, and different machines might need different kernel options (e.g. PS2 | usb1 | usb2 | usb3 for keyboard and mouse, or in BLFS different video drivers or firmware). In BLFS, for several packages you will need to do extra things if doing a DESTDIR or INSTALL_ROOT install and sometimes BLFS packages have to be installed as root even when using a DESTDIR. Specifically, you can remove /tools, but on x86_64 you should not remove /lib64. > Of course this is easy to fix but I want to suggest to add the creation of > the directory /lib64 in chapter 8.5 (when generating the final glibc), > because otherwise your whole final system depends on something created in > the toolchain. > > By just adding the directory /lib64 and the 2 links in my glibc-package does > the trick and my system is running again without anything from the toolchain > (as it should be). > > bye, > > Patrick > Glad you understand how to fix your packaging, but adding an unnecessary recreation of a directory to the book seems pointless. Until people can successfully build and boot a system, they should follow the book. After that, using your own scripts or other forms of packaging is fine and can contribute to the learning experience. But you need to keep an eye on how the book changes, and for each of us: if something in our scripts or packaging causes our builds to break, we get to keep both pieces. ĸen -- On average, the Panda feeds for 15 hours a day. This is the same as an adult at home under quarantine, which is why we call it a "Pandemic". -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
