Tim Tassonis wrote:
Hi List
In order to build a distribution based on the magnifient LFS/BLFS book
descriptions and scripts on how to build a Linux system, I've come
across three minor issues which maybe might get incorporated into the
next release of the book.
1. Shadow / util-linux overlap
shadow and util-linux both contain the following binaries:
- su
- login
- nologin
- chsh
- chfn
When strictly following the book, the util-linux package overwrites
them, simply because util-linux is installed after shadow. I have no
idea which versions are "better" or generally preferrable, they both can
be copiled with or without pam, I have no idea which ones I should
prefer, so I stuck to the shadow suite ones. Maybe a clarififation of
this matter could be added to the book.
When building util-linux in Chapter 6 building these packages is
intentionally disabled.
2. util-linux / eudev circular run-time dependency
Although it is not a problem when compiling LFS from the book, because
util-linux is already available from tools stage and eudev is simply
linked against that version, I still think it is a bit unfortunate, as
it semms that only one unimportant binary from util-linux requires
libudev. When you specify "--without-udev" when configuring util-linux,
it will build just fine, minus that one program and the circular runtime
dependency goes away. Maybe this could also be mentioned in the book. On
a side note: this is the only cirular run-time dependency I've come
across so far, so the book does an extremely excellent job in avoiding them.
The main reason for adding util-linux to Chapter 5 was to solve the
circular dependency. In a sense, all packages in Chapter 5 are there
for this reason.
3. no static libgcc and libstdc++ from gcc compile
The build instruction for stage 2 in "6.17. GCC-4.9.2" works perfectly,
but does not build static versions of libgcc and libstdc++. From a
run-time dependency view on systems with very few c++ programs (an
LFS-based system. for instance...) and, as I have read, also from a
general binary software distribution point-of-view for c++ programs, it
is nice to have the possibility of linking those two libraries
statically to a binary. It maybe could be mentioned in the book that
this can be achieved by adding --enable-static='libgcc,libstdc++' to the
configuration of gcc. Then, both static and dynamic versions of the
libraries are built and any c++ program might then link them statically
by specifying LDFLAGS='-static-libgcc -static-libstdc++' at the link stage.
Perhaps we ought to consider this. What do other devs think?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
