Robert Connolly robert at
Mon Sep 3 20:26:47 PDT 2007

In general you need pretty much all -dev packages. But there are exceptions 
when it comes to distributions using 5 year old packages with 40 backported 
patches and modifications. It works for them, but may not work well when 
building a vanilla system.

HLFS, currently, is vanilla with the exception of compiler options and some 
backports, but this may change one day (shadow-ssl). Modifications, like 
arc4random, are keep separated whenever possible so they're optional. I don't 
intend to ever lose compatibility with LFS. Patches add bug fixes, or 
security enhancements, while distributions can add all of the above plus 
performance, gui, and usability patches.

When HLFS first started it was just compiler options, and recently is adding 
unofficial patches for hardening. But more often than not package maintainers 
are willing to integrate these in to their package.

With all these complications, for the sake of developing HLFS, we found it's 
best to only be compatible with LFS as a host system. Otherwise the hour 
spent on finding out why Glibc doesn't build under Suse could be spent on 
hardening Glibc (for example).


On Monday September 3 2007 06:35:15 pm Robert Baker wrote:
> Indeed it seems rather important to follow this suggestion. When I first
> built an LFS system I used a suse system to build with. I can't remember
> the exact version, but it was some time ago before the novell buyout.
> Anyhow that build went fine. Since then I have taken to using debian on a
> few of my systems. I began a build friday using one of those systems. This
> ended in failures on glibc during building the temporary system. I went
> round and round looking for problems in other parts of the build leading up
> to glibc. Untill finally I decided to boot from an LFS live cd. Low and
> behold the compile completed without error.
> Anyhow it would seem a lot of heartache would have been avoided had I
> simply started from the cd to begin with. Sometimes these things just make
> me feel like an idiot.  :) Sent from my BlackBerry® wireless handheld
> -----Original Message-----
> From: Robert Connolly <robert at>
> Date: Mon, 03 Sep 2007 17:31:55
> To:Hardened LFS Development List <hlfs-dev at>
> Subject: Re: journal
> LFS (6.x), and HLFS, are the only supported host system for HLFS, partially
> because of things like this, and also because of trust. We want the host
> system to have Scrt1.o, for example, and to expect the Glibc tests pass the
> host system kernel should be vanilla, and then there's the bug below. Using
> LFS or HLFS as the host system is the only way to be sure that the host
> system is going to support the build of largely vanilla packages. Despite
> saying this, I've never had a problem with Slackware.
> robert
> On Monday September 3 2007 10:24:37 am goodoldmarty at wrote:
> > >> > I don't believe this is exclusive to my system, but that is
> > >> > possible. Otherwise, these issues are really a bit much for me to
> > >> > debug.
> > >> >
> > >> > Marty B.
> > >
> > > FWIW, I got a similar error from installing a distro (not hlfs)on a
> > > preformatted ext3 drive which I got rid of by removing  and recreating
> > > the journal. I wonder if ext3 has broken compatibility with earlier
> > > versions recently?
> >
> > I found some traffic on this issue in the LKML and GLIBC list. It seems
> >  some patches have introduced structure incompatabilities with previous
> > EXT3 filesystems. However; Ext3 does appear to work fine on a native
> > hlfs filesystem. I think this warrants disclosure in the book.
> >
> > Marty B
> --
> FAQ:
> Unsubscribe: See the above information page

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list