The new build method is in...

Jeremy Huntwork jhuntwork at
Sat Dec 6 15:47:39 PST 2008

Greg Schafer wrote:
> No. You've also omitted perhaps the most interesting feature of the whole
> thing - the ability to migrate from a 32-bit system to a 64-bit system. As
> it currently stands, you're forcing folks to start from a 64-bit system if
> they want 64-bit. Useless.

Greg, c'mon. You know it's not useless so why must you be so harsh in 
your appraisal? You well know the technical benefits the basic method 
brings with or without the specific benefit to migrate from 32 to 64. 
You've littered this all over our lists for the past month or two, 
throwing around such phrases as 'I would not touch the old method with a 
10-foot pole'. The basic methodology is there, with the benefits of 
being better able to separate from the host.

Anyway, the specific example you cite here of being able to migrate from 
a 32-bit system to 64-bit does in fact work perfectly, _if_ you have a 
64-bit kernel available. I'm currently building a 64-bit system on the 
32-bit LiveCD and it's working fine. :)

OK, OK, I realize the point you are trying to make. In DIY you can take 
a 32-bit distro (with a 32-bit kernel) build the 64-bit libs from the 
32-bit host and then build a 64-bit kernel and reboot, finishing the 
build in 64-bit. You have this before binutils pass2:

[[ $DIY_TARGET == x86_64* && $(uname -m) == i?86 ]] &&
	{ echo 'build a 64-bit kernel and reboot into it!'; exit 1; }

This is all excellent, but it is another feature that I would like the 
LFS community to discuss before we implement. When we decide what we 
want to do wrt to handling the BOOK with optional paths (multilib or no 
multilib, require a reboot in the middle of the build...) we can strip 
out the stuff that makes it linear right now and give the user more 
options at the beginning. We can turn the initial setting of the LFS_TGT 
variable into something the user sets manually.

> All this `case $(uname -m) in' stuff you've
> added is bogus.

Knock it off. I don't come to DIY and disparage your work. This is not 
'bogus'. It's a valid command that works fine in this initial step where 
LFS is still a very linear book.

Did you really expect this to be absolutely perfect on the first import 
into LFS? You know how LFS works and that it is a slow-turning ship. I 
was actually surprised that there wasn't more fuss concerned with 
incorporating your new method. Once I get some more input, we'll start 
moving in the other aspects.

> You'll have to rethink how you're going to handle this
> aspect if you want it to work.


> The other thing you've omitted is proper attribution. A simple "Thanks,
> me" is not good enough for something this big. The LFS changelog is not
> perpetual. You of all people should know how much time and effort goes
> into engineering this stuff. Some extra words next to my existing entry on
> the Acknowledgments page will suffice. "... Technical Writer and Architect
> of the Next Generation 64-bit-enabling Build Method" or similar.

Shall I just use the acronym? You'll be the T.W.A.N.G. 64BM. Heh, I 
kinda like that. :)

But, yeah, no problem. If you can think of a better term, I'll use that 

While we're agreeable to these sorts of edits, I wonder if you'd be so 
kind as to finally remove the disparaging and now inaccurate statements 
about LFS from your Reference Build and website?

> It's a good question. It's easy for me in DIY because I actively target
> scripting. Because LFS targets the interactive command line, you'll have
> to be careful not to introduce too much awkwardness. But whatever you do,
> you *must* introduce a 32-bit Glibc in the 64-bit case. I'm even
> considering dropping pure 64-bit in DIY because its usefulness is limited.

Yes, the more I am around pure 64-bit, the more I agree with you. Even 
if you hardly use the 32-bit libs at all, just having them there and 
available makes the system that much more valuable.


More information about the lfs-dev mailing list