On 2021-03-28 23:37 +0200, Patrick Frisch wrote: > > Am 28.03.21 um 14:10 schrieb Xi Ruoyao: > > 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. > > As you said, /lib64/ld-linux-x86-64.so is absolutely essential for the > system, so in my eyes it's no harm to recreate the link in Chapter 8, I > would be happy with a simple > > ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
First, it should be: ln -sfv ../lib/ld-linux-x86-64.so.2 /lib64 Second, it's potentially harmful. If someone mistype the command (for example, '..' is mistyped as '.') then the lfs chroot environment will be broken. The only ways to fix are: (1) recreate the symlink from the host distro; (2) use sln command (which is a utility like ln, but static linked). > in chapter 8, no need to recreate the directory, your example is not > valid since /bin is used implicitly several times in the build process, > /lib64/ld-linux-x86-64.so.2 (and therefore /lib64) is touched only once > in the whole process. Every other object is recreated in any way in > Chapter 8, only that little thing is left like created in the toolchain, > since "it is unconvenient and unnecessary". Not every. For example, Linux API headers. Files are recreated or rebuilt if we can't guarantee that it's content won't change. > > > > > 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. > I'm very long in the LFS business and in ancient times, where the > toolchain was limited to $LFS/tools, the final test was that the system > is usable without $LFS/tools. Then you didn't subscribe to lfs-dev, and didn't see the tickets on trac. The problem is if you rebuild a package in the final LFS system, the generated executable or libraries will be different than the one compiled in chapter 08. It may be usable, but not settled down. If only considering "usable", it's even possible to just copy some libraries and executables from some distro, and make a usable system. > > > 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. > > If you do an ldd on the temp tools, you will find the exact libraries as > in the final system. I would bet, that these tools run in the final > system like the later created ones. Anyway, I'm of course with you to > recreate them with the final libs in the build system. But I don't like > the the argument, it is not necessary to create it, because the > toolchain version runs in the final system. This is true for many > libraries and/or programs :-)..... ldd output is meaningless here. If there is no rpath hard coded in the executable, ldd will output "correct" result even if that executable were linked to some library from *host distro* at build time. And it's not just the libraries. Paths to headers in the debug symbol will be different, for example. And with autoconf building system many features are tested by configure script. Some of those tests are not possible during cross compilation, so workarounds (actually unneeded in the final LFS system) are enabled, or optional features are disabled. The reason is not "toolchain version runs". The reason is "we can guarantee toolchain version is exactly same with the final version we should use". ln -s ../lib/ld-linux-x86-64.so.2 $LFS/lib64 does: (1) create an inode for $LFS/lib64/ld-linux-x86-64.2, and mark it a symlink (2) write the *path* (a byte string), "../lib/ld-linux-x86-64.so.2" into the inode It does *not* copy anything from $LFS/lib/ld-linux-x86-64.so.2 into $LFS/lib64, it even doesn't care the content of $LFS/lib/ld-linux-x86-64.so.2. When the kernel opens /lib64/ld-linux-x86-64.so.2 in the LFS chroot environment or the final LFS system, it does: (1) read the content of /lib64/ld-linux-x86-64.2, and find out it's a symlink, its content is "../lib/ld-linux-x86-64.so.2"; (2) resolve the symlink, by opening "/lib64/../lib/ld-linux-x86-64.so.2", i. e. "/lib/ld-linux-x86-64.so.2". (3) since /lib/ld-linux-x86-64.so.2 is also a symlink with the path "ld- 2.33.so", the resolving continues, opening "/lib/ld-2.33.so". /lib/ld-2.33.so is overwrited by the installation Chapter 08 glibc. So in the final system the dynamic linker from the final glibc is used. Nothing from the toolchain is kept here, except for a symlink. A symlink is just a special text file: /lib64/ld-linux-x86-64.so.2 just contains one path "../lib/ld-linux-x86-64.so.2". It does not make sense to explicitly rewrite it with the *exactly same* path. Would you rewrite your "Hello World" program after a system upgrading, just because "/usr/include/stdio.h" may be changed and there is a "#include <stdio.h>" in your program? :) -- 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
