On Mon, Jul 30, 2007 at 08:03:43PM +0200, M.Canales.es wrote:
> If some bug is found later we always could do a 6.3.1 release.
>
> Plus, I would start today with the preparative to can merge the x86_64 branch
> into trunk.
I've been thinking about this some more recently. I really think it's
not worth the time and effort (at least not now) to add the extra
complexity to the XML/XSL to render two separate books for x86 LFS and
x86_64 LFS. The command changes are so minimal that in the end, there
would be very few differences at all. Just for the sake of review and to
show how I would resolve the differences in one book, here's what we
would need to change:
1) After the installation of binutils-pass1, run:
ln -sv lib /tools/lib64
This, being just a symlink has absolutely no effect on x86. We can
put a note that it can be skipped for 32-bit x86, but it hurts nothing.
2) All builds of GCC get the switch '--disable-multilib'. Again,
harmless for x86. Again, we can put a note that it could be left out, if
desired, for x86.
3) Section 5.7, 'Adjusting the Toolchain'. Here's where it gets a little
fun. But still, easily adapted to fit both situations. Somewhere, at the
beginning of the book, we set a LINKER (or some such) variable,
depending on arch. Easily scripted via `uname -m` for the sake of
accuracy. We also take into account that gcc will make use of the /lib64
directory internally, so we account for that, too, in our adjusting
command. Like so:
gcc -dumpspecs | sed "s@/lib[64]*/$LINKER@/tools&@g" \ (etc.)
4) In gcc pass 2, currently there's a sed command that deletes the
multilib spec in gcc/config/i386/t-linux64. I don't think this would
have any effect on x86, but I haven't tested. Also, there have been some
inconsistencies between what I have found wrt the purpose of this
removal and what Greg has found over at DIY. I want to do more testing.
In any case, it is one command and it doesn't seem likely to me to
affect a non-multlib, non-64 bit arch.
5) Creating Directories. Again, adding the {/usr,}/lib64 symlinks. Same
comments as in item 1.
6) Bootloader. This one is probably the biggest. Legacy grub is probably
still preferable for x86. I see 3 options here:
a. Convert to lilo for both (dependency on bin86 which requires a
patch for x86_64)
b. Convert to grub2 for both (untested by me, but I believe it works
for both. Joe Ciccone has more info.)
c. Tell users to install grub via their host system. (Most have it
these days. Wouldn't work for the 64-bit only LiveCD as of now.)
7) Last one. We would need to alter the output of the sanity tests to
accomodate both instances. Or, at least, add more descriptive notes
showing *what* exactly we are looking for and what the differences would
be with a different target triplet and dynamic linker. To me, this would
be a good thing anyway as it makes the instructions that much more
educational and less robotic.
I'll follow the decision of the community on this one, but to me, it
would be a simple thing to merge both possibilities into one set of
instructions. I believe making the LFS book just a little more
architecture agnostic does more to help teach concepts.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
