On Tuesday 24 July 2007 12:10, Matthew Burgess wrote: > On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > > Matthew Burgess wrote: > >> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork > > > > <[EMAIL PROTECTED]> wrote: > >>> The question is, do we want x86_64 to be a separate book, or simply > > > > roll > > > >>> these small changes into a conglomerate book with x86? > >> > >> I'd certainly prefer them to be in the same book, > > > > My biggest problem with this approach is that it gets to be a nightmare > > to edit. But, it is do-able. > > Hmm, that "nightmare" seems a bit extreme. Certainly, for native x86-64, > which is the only additional target we're contemplating at the moment, > having 2 paragraphs (or small sections at the most) in the book surrounded > in the relevant profiling syntax, doesn't seem too onerous to me. Once in > there, I doubt they'd need amending much - probably only if newer GCC > versions change relevant portions of the specs file. > > Of course, if more targets are desired in the future, our approach may well > need to change, but for now I think x86 & x86-64 native builds capture the > largest section of the LFS audience and anyone else can continue on to > CLFS. > > Regards, > > Matt.
Speaking from experience building LFS on x86, ppc (32bit) and sparc (both 32 and 64 bit), except for the dynamic linker and the boot loader, there is little to no difference in the instructions when building on different architectures. So with minimal effort the book can be modified to apply universally. The only big issue is 32bit vs 64bit. As someone already mentioned previously in this thread, there are almost nil benefits in building a 64bit userland. Very few applications can make use of being compiled 64bit. So on ultrasparc (64bit sparc) I've always done what the ultrasparc gurus have suggested for many years, 32bit userland + 64bit cross compiler and 64bit kernel. So if you decide to support x86_64 you'll end up needing a cross compiler just for the kernel. Oh, and you don't actually need multilib glibc either if you go with pure 32bit/pure 64bit userland. Even though 64bit CPUs sold outnumber 32bit CPUs sold at the moment, the installed base of 32bit CPUs is far larger than 64bit CPUs. So I suggest LFS remain for the foreseeable future purely 32bit userland. Ideally, parts of CLFS would be merged into LFS. I never understood the need for CLFS. Presumably it was for people like me who were building LFS on non-x86 architectures. But CLFS is just complicating what is a rather simple procedure. The only useful things in it are the extra packages needed for different architectures. And the instructions to build a cross compiler. Everything else is just LFS. I understand the reluctance of the LFS devs to explicitly "support" non-x86 build as someone has to spend the time and effort to test the instructions on those other architectures. But I still maintain that since you're discussing the inclusion of x86_64, you might as well consider modifying the instructions minimally so that, even if the book doesn't mention non-x86, the instructions will still work. I'm talking about the dynamic linker and the sed command fixing the gcc specs. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
