2009/9/18 Nathan Coulson <conat...@gmail.com>:
.
>
> I have been experimenting with a multilib LFS System (where /lib,
> /usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used for
> 32bit). I wanted something as close to LFS as possible, primarily
> 64bit, but just enough 32bit so if I wanted to compile something
> 32bit, I could.
>
> In fact, the only 32bit libraries I install, are e2fs, glibc, ncurses,
> udev, utillinux, and zlib. [The only 32bit program I use is wine, I
> didn't want a full fledged 32bit system just for wine]. If all I
> wanted was a compiler that could build 32bit code, I could probably
> drop e2fs, ncurses, udev, and utillinux from that list.
>
> The toolchain I use for compiling the system is based on our previous
> work, I could not make the current directions build a multilib
> capable gcc toolchain. (I am not an expert when it comes to tool
> chains though)
>
> If you wish, I could review my buildscripts, and note where I deviated
> for a 32bit build. (From the email, I get the sense this is probably
> not a immediate goal)
>
>
> My Thoughs when I designed my MultiLib LFS System:
> - A Typical user would probably not need every 32bit library that is
> build in a base LFS Build if they have a 64bit version, but you would
> still want the ability to install it at a later date [GCC Multilib
> Compiler, which requires zlib32bit, and glibc32bit. binutils/gcc
> should be build with multilib support]
> - Most programs like to install in /lib or /usr/lib by default, which
> in a standard multilib system. Some programs take a lot of effort to
> install in /lib64 and /usr/lib64. I decided to use /lib and /usr/lib
> as 64bit directories and /lib/32, /usr/lib/32 as 32bit. [For me, this
> was the best decision at the time. Kept things clean, and close to
> LFS defaults. I am not sure what would be the best in the official
> book. Either /lib,/lib64, of /lib32,lib I suppose].
> - Some programs have their own program to find paths, ex:/
> ncurses-config. I did not like the idea of using something like
> ARCH=32 or ARCH=64 for installation, so instead I threw such programs
> in /usr/lib/32/bin. [I noticed that CLFS/CBLFS use this to specify
> which program to run]
> - in LFS, we prefer to stay as close to the defaults as specified by
> the package maintainer.
>
> On my system, if I want to build a program 32bit, I could use
> PATH=/usr/lib/32/bin:${PATH} CC="gcc -m32" CXX="g++ -m32"
> PKG_CONFIG_PATH=/usr/lib/32/pkgconfig
>
> if I want to build 64bit, I would not have to deviate from LFS/BLFS,
> except in a few odd cases.
>
To me, this sounds a very sensible way to use multilib on x86_64:
only build 32-bit when absolutely necessary. Of course, as people
have already noted, it violates the fhs. For me, that isn't a
showstopper.
ISTR debian has used /usr/lib32, but I could be wrong.
On ppc64 (my last build was a variation of clfs, using
--with-cpu=default32 so that userspace is 32-bit for better
cache footprints and the kernel is 64-bit), I had to build both
sizes of gmp, mpfr, zlib (similarly PPL and CLooG which LFS
ignores).
I've built full-multilib in the past, and learned a lot from
building a working gtk desktop on it, but I don't have the
time or inclination to keep building multilib desktops.
Certainly, fixing up runtime stuff for gtk and pango on
a desktop where some of their users were 32-bit and others
were 64-bit was *interesting* until I cracked it.
ĸen
--
After tragedy, and farce, "OMG poneys!"
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
