Thinking forward LFS-7.0
akuktin at gmail.com
Fri Mar 18 03:11:17 PDT 2011
>On Mon, 14 Mar 2011 20:56:36 -0500
>Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> I've read about 15 messages on this topic and will try to incorporate
> the relevant areas in my response.
> Ken Moffat wrote:
> > I will agree that building a bi-arch desktop (that is, both 32-bit
> > and 64-bit Xorg, with some applications as 32-bit and others as
> > 64-bit), was a very educational exercise when I did it. That was
> > back in the gnome-2.1x days - the real fun was in making some parts
> > of gnome 32-bit and others 64-bit). Fun, but pointless. On x64_64,
> > modern software runs fine as 64-bit.
> This pretty much fits into the same category as above. The only
> reason for lib64 to exist is for those proprietary packages that have
> not been updated for 64-bit operation.
> VirtualBox? A system owned by Oracle? I don't think I'm interested.
> Besides, there is now a 64-bit version. Does it use 32-bit libraries?
> Wine? So you can run proprietary WIN applications? See my comments
> about proprietary binaries.
Also, last time I checked (23.1.1), GNU Emacs was 32-bit only, and
there were no plans of porting it to x86_64. Which I found unusual,
given that it is one of the most ported pieces of software in the world.
Anyway, there is at least one other approach to building a multilib
system. In this approach, one would first finish the pure64 system as
he wishes. Then, a dedicated directory tree is created (in my
case, /opt/linux32), and is populated in the same way the
croos-toolchain from CLFS is build. It's a little tricky, there are
some interesting workarounds one has to use, but it can be done. I did
it last time more than a year ago, but still have all the
instructions I used then and can share them, should anyone be
Note however, that the 32bit subsystem is not self-sufficient, that
means it can not be used to bootstrap itself. In the event of
rebuilding, one would still have to use the master (64bit) toolchain to
first build the 64bit LFS, and then spawn the offspring 32bit
subsystem. This is due to a number of assumptions Glibc (I think.. or
either GCC or Binutils) makes on the positions of it's components.
Yeah, I think it was something about /usr/lib/crti.o and friends.
More information about the lfs-dev