Nathan Coulson wrote: > On Thu, Sep 17, 2009 at 2:31 PM, Matthew Burgess > <matt...@linuxfromscratch.org> wrote: >> On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs >> <bruce.du...@gmail.com> wrote: >>> About the only other thing I can think of that is a candidate for >>> LFS would be to add instructions for multi-lib. >> I think I'd like to see that work go in too, but I have no >> experience of it and don't have suitable hardware to test against >> either, so doubt I'd be able to help out much with it.
The new build I was talking about in the last message was actually
multilib, as well. (As was the CLFS build that was used as a host.)
More notes on that below...
> 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.
Hmm. Apart from not running binary-only programs (/lib/ld-linux.so.2
really does need to exist... :-) ), and apart from not adhering to the
FHS, this probably works.
> 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.
Since the book's e2fsprogs doesn't include any libraries used by any
other tools anymore (just libcom_err, libe2p, libext2fs, libss), because
libblkid and libuuid are from util-linux-ng, there's no point in
installing two e2fsprogs (IMO).
I compiled as much as practical twice; currently that's:
bzip2
flex (libl.a)
gdbm
gettext
glibc
libtool (hmm, not sure why...)
lvm2 (for the devmapper libraries)
ncurses
pkg-config (built twice to avoid mucking with PKG_CONFIG_PATH in the
environment on future builds; I just use the multiarch_wrapper instead
and set --with-pc-path=/usr/lib{,64}/pkgconfig depending on the build --
but that may or may not work for LFS)
readline
util-linux-ng
zlib
That's along with most of xorg (yeah; ouch), expat, fontconfig,
freetype, gpm, lib{png,xml2,xslt}, openssl, pixman, popt, python,
sqlite, and tcl. More stuff is coming, as I slowly work through BLFS
(and take a look at CBLFS for pointers to where stuff goes wrong). Xorg
at least starts up, though. \o/
> 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)
Yeah, to get a cross compiler, I followed most of the DIY refbuild
instructions, along with a few minor changes from CLFS 1.1.0. (Note
that newer CLFS versions have drifted a lot more from LFS, with their
adoption of eglibc, and their inclusion of cloog and whatnot for GCC.)
I'm still not sure if it actually works, but it seems to. Various
packages pass their regtests, at least, both in 32-bit and 64-bit
mode...
(Oh, and when doing the chapter 6 toolchain adjustment, I didn't use
DIY's /tmp/specs setup, but LFS's "use the real specs file" change. I
also didn't use DIY's -B args, but only because I built the system
through coreutils in chapter 6 twice; on the first build I did the start
files that way, but kept getting test failures -- these ended up being
the kernel I was running having a broken dup2() -- and on the second
build, I decided to use the LFS startfile_prefix_spec change instead.)
> 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)
Yeah, I have logs for chapter 6 as well (and maybe chapter 5, but that
would depend on ~lfs/.bash_history being complete; I don't know if it
is...).
> 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]
Yeah, maybe. The issue might be with a package like util-linux-ng: you
don't want to overwrite all the 64-bit binaries if you later decide to
go install the 32-bit libuuid / libblkid... :-/
> - 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].
I'd prefer /lib and /lib64 to match the x86 ABIs for the location of the
dynamic linker, for the ability to run both 32-bit and 64-bit programs
that weren't actually compiled from source. But that's just me... :-)
> - 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]
Yeah, it is a bit more complicated, setting up a USE_ARCH. There are
sometimes configure switches that help a bit (--program-suffix=-32 and
--program-suffix=-64 is useful if the *only* program installed is the
config program, or on a package like pkg-config). But they don't remove
all the pain, either.
> 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
And since I'm *also* using the package-user hint (at least in the last
form it was updated to), I have this in the package-user build script by
default:
USE_ARCH=64 CC="gcc -m64" CXX="g++ -m64" ./configure --prefix=/usr
--libdir=/usr/lib64
which I of course have to change for lots of packages as well (to add
other required options), but it gets at least the basics set.
config.site also helps with this, if you have it set to different files
for 32-bit versus 64-bit. (Assuming the script in question is actually
autoconf.) Though I didn't do that myself.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
