archaic at indy.rr.com
Tue Jan 20 15:47:27 PST 2004
On Tue, Jan 20, 2004 at 02:38:16PM -0500, Robert Connolly wrote:
> HJL is only needed for et_dyn.
So unless et_dyn will be in the initial book release, we can stick with
FSF for the time being. Then maybe when the time is right, FSF will
support it and we won't need to change anything. Of course, if et_dyn is
ready to go, then we should probably go ahead and drop in HJL and it's
> Attr/Acl needs libtool.
Then we either rearrange chap 6, or add it into the /tools after the
fact. That may get interesting.
> The coreutils acl patch adds a dependency for bison and bison needs
> m4. Probably flex too.
If we are always going to be living on the edge regarding m4, flex, and
bison, how about just putting them in and forgetting about it?
> By skipping chapter 5, glibc, binutils, and gcc wouldn't have any
> gaurds in them.
It would if you built glibc twice in chapter 6. It doesn't really matter
where you decide to build it twice as far as proplice goes. The concern
is for the overall affect. That is, someone who at first builds LFS not
knowing/thinking about HLFS should have to wipe a perfectly good /tools
or base LFS (depending on if we start from chap5 or chap6). He has the
clean tools already in his possesion from which to build glibc twice
using the patches. But for people who start LFS with the intention of
build HLFS, pointers can be added to the LFS at the proper places saying
"if you want propolice support, follow this link" which will put them
into our pages that builds it right. I'm seeking integration with the
LFS book. HLFS is an extension, though in a different manner than BLFS
since we actually disassemble and re-assemble the system.
"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
- Constitutional scholar and Supreme Court Justice Joseph Story, 1840
More information about the hlfs-dev