On 2021-03-28 12:42 +0200, Patrick Frisch wrote: > > Am 28.03.21 um 00:13 schrieb Ken Moffat: > > 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 > > So, you do "recreate" several directories in Chapter 7.5 "Creating > directories", you overwrite everything in $LFS during the build process, > but you are not willing to do this "unnecessary recreation"?
In Chapter 7.5 the mkdir commands are with -p. If the directory already exists, it won't be "recreated": mkdir -p just skips the directory. We shouldn't solely rely on some package's building system to create a directory: what will happen if that package gets some change and stop to create the directory? So mkdir -p is used to "create the directory if it does not exist". But /lib64 is created by ourselves explicitly, not by some package. > This /lib64 is a central directory, because it's linked in to every > binary in the system and you use the one created in a temporary stage. I'm not a native speaker so I'm not sure what "linked" means here. But I can tell it's not the "linkage" (done by a linker). The path, "/lib64/ld-linux-x86-64.so.2" (a path, just a byte string, nothing about the content of the file pointed by this path) is hard coded in ELF executable headers. The kernel reads the header and invokes /lib64/ld-linux- x86-64.so.2 to load and run the executable. There is no reason we should recreate /lib64 or /lib64/ld-linux-x86-64.so for this process. It's just like saying: "The shell scripts in the final LFS system contain a path, /bin/sh, in it. So we should run mkdir -p /bin at the beginning of chapter 08, as we shouldn't use the one created in the temporary stage." It's obviously ridiculous. > You decided to use the $LFS directory outside $LFS/tools in the > toolchain phase for convenience, I already had a discussion about that > and I can see the advantages of this approach, but for my understanding, > nothing in the final system should depend on anything in the toolchain, > and creation of /lib64 and the links therein belongs to the toolchain. No. It's not for convenience. It's to prevent any occurrence of hard coded paths to "/tools/*" (which will be deleted later) in the final system. In LFS 9.1 Pierre found a dozen of such paths. > If you argue about unnecessary recreations, I could argue as well about > recreation of tools like grep, gzip or xz, the versions created in > Chapter 6 should work perfectly fine in the final system too nowadays:-). Temporary grep, gzip, xz, and other temp tools are produced by some complicated cross building process. They may contain paths to directories or files not exist anymore in the final LFS system. But ($LFS)/lib64/ld-linux-x86-64.so.2 is created by a single ln -s command, and it only contains one path "../lib/ld- linux-x86-64.so.2", to a file which exists in the final LFS system. -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University -- 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
