Jeremy Huntwork wrote: > ...Mostly. > > With revision 8755, the new build method from DIY is in place with the > exception of support for multilib. (More on that in a second.) > > I tried to make as many textual changes as I could to keep the accuracy > of the book on a high level, but I'm sure I missed some things that > referenced the old build methods. I would appreciate it if you all could > take a second to read through Chapters 4 & 5 particularly to help spot > discrepancies. Until the book renders tonight/tomorrow, there is a > rendered version here: > > http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk > > There is no technical hindrance to bringing in multilib, the changes are > minimal. The effect is not so minimal. I would like to know people's > thoughts on how to deal with multilib in LFS. Specifically, how do we > handle for x86, where multilib is not an option? Do we just have a note > that says 'for 64-bit architectures only'? If so, how do we handle this > in jhalfs? > > Another side note, jhalfs can't currently handle the new build method > becuase it hard-codes the build user's .bashrc file. A slight tweak in > jhalfs to match what is now in Chapter 4 should take care of it. CCing > George Boudreau so he can fix it up when he as a second. > > Thanks! > > -- > JH > Couple of minor things
1: Chapter 6.15 - If you aren't bootstrapping the compiler, you wont be using the newly created binutils to build your new gcc. Either bootstrap or add CC="gcc -B/usr/bin" to override GCC_EXEC_PREFIX. 2: Just to bring up again the use of -B/foo/lib to set startfile search paths. We've been through this before (nearly three years ago) http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg05545.html Nothing has changed since http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353#c7 LFS isn't affected by the "-specs handling bug" as we do not pass -specs=/some/specfile on the gcc command line (we regenerate one in the standard place in ch 6.10), so we can edit the specs to our hearts content, therefore dont need to hack gcc.c itself. STARTFILE_PREFIX_SPEC is unpalatable to some for whatever reason, yet it still exists in the gcc code to provide the only mechanism to override the search path used for finding startfiles when cross-compiling (see gcc.c line 6332, read the code and comments) You should however be able to use/override STANDARD_STARTFILE_PREFIX_1=/tools/lib (continue nullifying STANDARD_STARTFILE_PREFIX_2) instead if you are doing a native build (which you are) and find STARTFILE_PREFIX_SPEC objectionable (for whatever reason). Note: startfile_prefix_spec and standard_startfile_prefix* ARE expanded by the multilib spec out of the box. There is no need for replacing things removed by gcc devs from gcc.c circa 1999, use what is provided for its specified purpose. Just some thoughts Regards [R] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
