[LFS Trac] #2094: Add a new section for build results

Jim Gifford lfs at jg555.com
Sun Oct 21 02:29:21 PDT 2007

Alexander E. Patrakov wrote:
> Justin R. Knierim wrote:
>> I cannot say much about your first point, I have not heard of this 
>> issue.  Has a ticket been submitted?
> No, sorry.
>> This topic though is about LFS, not CLFS XML.  Even if LFS must 
>> re-invent the wheel, surely contacting those who have already invented 
>> it would be of some benefit?  Even just emailing the list, or one of the 
>> developers, or being in IRC pinging us with questions, would involve 
>> help unite efforts and save valuable time.
> OK. There is, however, one more thing that I have already mentioned in 
> one of the "x86_64 bug" threads. CLFS does not take advantage of the 
> fact that in many situations (referred to as "not-really-cross") the 
> host can execute target binaries. For such situations, work is underway 
> to create a third build method, that switches from cross-compiling to 
> the native method after glibc, not after the entire Chapter 5. The aim 
> is to future-proof the toolchain against such "compilers incompatible 
> with the host glibc or headers" bugs, without losing the above-mentioned 
> advantage due to cross-compiling. There are, however, difficulties on 
> this way, and there is really nothing to demonstrate yet. Also, CLFS 
> should stay for really-cross build scenarios.
Alex, I've been trying to search for this thread, but don't seem to find 
it anywhere on the lfs-dev list, could you provide a link to it.

As far as CLFS not taken advantage of the existing toolchain, we build 
our own instead of depending on the host distros, this gives you a 
controlled environment to work with. We have people every day who submit 
ideas or possible changes via our support lists or IRC. We don't expect 
everyone to be able to edit the XML, but if they make valid and proven 
remarks we will make the necessary changes to the book.
As far as the XML goes, if you have ideas, pass them on and Manuel can 
validate your findings.

I agree with you that CLFS should stay on it's current path as a 
separate, but related book to feed information to and from LFS.

More information about the lfs-dev mailing list