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"?
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.
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.
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:-).
My packaging system works docker-like (well, I "invented" it long before
docker appears :-)) in isolated stackable containers. With this approach
you don't need to change the instructions in any way, everything is done
exactly like written, that is why I stress this a bit :-), because I
have to modify the instructions at exactly this place.
I do this mainly for fun and for educational reasons, so I can live with
it, but for constistency reasons I would vote for inclusion of the
statements in Chapter 8.
Have fun,
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
