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
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".
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.
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 :-).....
bye,
Patrick
--
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
