>On Mon, 14 Mar 2011 20:56:36 -0500 >Bruce Dubbs <bruce.du...@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 interested. 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. -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
