plans and wishes

Ryan.Oliver at pha.com.au Ryan.Oliver at pha.com.au
Wed Jan 14 18:04:08 PST 2004






> is a noble goal and quite logical. But my ICA stuff which is based on
> comparing actual bytes leads me to believe that this notion is not
> that important, mainly because the core toolchain is already so
> beautifully taken care of in early Ch 6.

Too true, but hey, I'm anal :-)

Ch6 after the toolchain is open slather, even if we do it
alphabetically by a naming quirk the autotools, bison, coreutils will still
be built early ( though also best to get m4/bison/flex/make
built early ch6 ).

As long as the gnu dev suite is in place early we keep our build
relatively future proof, regardless of what gets thrown our way.
(another reason for the initial ch5 build sequence,
though m4/bison/flex have been dropped from LFS-5 ch5 )

Ideally you'd also have libtool near the start too in case of
future invasive patches requiring the whole libtoolize/autoheader/
automake/autoconf routine...

The one thing your ICA tests wont show up is the difference between
ch5 binaries/libraries and ch6 binaries/libraries
(or are you comparing ch5 to 6 stuff after ripping out the .o files
from the .a archives ? if so give me a good whack with the cluebat).

/tools is a scratch migration area, the tools are updated and should
function identical to our ch6 ones but there is always a possibility
in future that they could become "tainted", they are still built
outside the chroot so should be considered "semi-trusted"...

But again, hey, I'm anal ;-)

[R]




More information about the lfs-dev mailing list