Jeremy Huntwork wrote: > Can we resolve any actual differences between the projects (and > individuals making up the projects) and put aside any perceived disputes > and work together in a more unified manner again? If so, what are we > willing to do to be more unified? What possibilities are there?
IMHO, LFS should not blindly copy anything. Especially since the goals are different: CLFS can produce any architecture from any, DIY depends on the fact (or, in different words, essentially exploits the fact) that the host kernel can run target binaries. My point is that the goals are essentially different, and thus, for technical reasons, the techniques _should_ be different. [below I map all chapter names to LFS equivalents] Obviously, in the case where the host kernel can't run target binaries, cross-compiling the entire Chapter 5 (as done in CLFS) is indeed the only solution. However, by cross-compiling the entirety of Chapter 5, CLFS, paradoxically, becomes more dependent on the host binaries than DIY. To see what I mean, consider the following. In x86 -> x86 DIY, Chapter 5 Gawk becomes available as soon as it is built (this is a plus). In x86 -> x86 CLFS, Chapter 5 Gawk just sits there, and all subsequent packages use the host Gawk while building. To me, this looks like deliberately ignoring an advantage of host-target compatibility. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
