Onward branch

Robert Connolly 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-, 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
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080911/0dbf5efc/attachment.sig>

More information about the hlfs-dev mailing list