robert at linuxfromscratch.org
Thu Sep 11 17:14:33 PDT 2008
I haven't started writting the new book because I'm still working on a couple
I tried gcc41, gcc42, gcc43, binutils-2.18, and binutils-184.108.40.206.9, with
glibc-2.8 and glibc-20080901. The newest toolchain I could get working,
without test suite errors, without patches, is gcc42 with
Both glibc-2.8 and glibc-cvs have some test suite bugs that test glibc's
programs/libraries installed in /, so 'make install' needs to be run
before 'make check'. There is no complete patch to fix this. Installing
before testing is a workaround, and I don't see it as a serious problem
because we're still testing the glibc we just installed.
gcc43 causes one math error in glibc's tests. I'm guessing it's a bug in gcc,
and not glibc.
Gcc41, gcc42, and gcc43, produce math errors in glibc's tests with various
optimizations, such as -mtune=i686 (gcc's default), and -O3
(from --enable-omitfp). My best results were always
with '-march=i486 -mtune=i486' (--with-arch=i486 --with-cpu=i486 when
building gcc). Glibc's test suite may test gcc's math precision better than
other packages which depend on it, so I think it's best to avoid these
optimizations, including disabling them in packages which use them by default
(like openssl using -O3), at risk of losing math precision.
Binutils recently started a 2.19 cvs branch, so a new release should be near.
This Binutils depends on Zlib to pass tests, but is not necessarily needed
in /tools because so far nothing uses the compression features from Binutils.
Zlib will need to be installed before Binutils in the final system though.
For the new book I want to use cvs snapshots of stable branches, when they are
available. Glibc-2.8-cvs is in tarballs at sources.redhat.com, gcc-4.2-cvs
snapshots are at gcc.gnu.org. So far no one is packaging
binutils-stable_branch, but it might happen. Or, these can be downloaded with
cvs/svn on the host system and packaged ourselves.
Some daemons still run as root, even with privilege separation, like fcron,
dhclient, etc. The kernel/linux capabilities of these processes can be
dropped, but the uid is still 0. If root owns everything in /bin, /usr, and
so on, then these processes still have permission to modify or replace core
system files. Installing packages as regular users would limit this, so I
think it'd be a good idea to integrate the more_control_and_pkg_man.txt in
the final system. This hint is about 3 years old, so it may need some
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev