LFS 64bit - thoughts
conathan at gmail.com
Wed Oct 1 00:33:18 PDT 2008
I noticed one person mentioning 64bit LFS on a previous post. It made
me wonder how LFS may address this in the future.
On my own, I took the multilib plunge about 6 months ago. (sortof a
hodgepodge of LFS's buildsystem, and a few occassional CLFS patch's).
I had the following ideals in mind in the construction of my own
system. (I dont know how close these are to LFS values)
-I wanted a pure 64bit os, or at least a system where 32bit could be
added on later. (To this end, I built a multilib gcc/glibc/binutils,
but no other 32bit libraries unless I specifically had a program link
-I dont like the idea that if I was to install a 32bit version of a
package, that it would overwrite the 64bit binaries. (goes against my
first idea, where I wanted 32bit as a addon). [although this one has
caused a few headaches]. I know one can install the 64bit version
after, but it just feels wrong.
-I like the concept of building the simplest system first, and giving
options later in BLFS. (such as the 32bit environment).
-I prefer to use standards (if appliable) to find the location of
32/64bit libraries. CC=gcc -m32 is smart enough to find /usr/lib,
while gcc can see /usr/lib64. I also found that overriding
PKG_CONFIG_PATH to /usr/lib/pkgconfig or /usr/lib64/pkgconfig is a
great way of helping a config script find it's dependencies.
-CLFS/BCLFS has done alot of work to make 32/64bit buildsystems work
relatively seemless, but I do not like the concept of the
multiarch_wrapper they made. (Saying that, I dont know of a better
solution). Most packages seem to use pkg-config either in conjuction,
or instead of programs in /usr/bin that tell you where to link
against. That is not the case for all programs though.
note: more details on the multiarch wrapper can be found at
Nathan Coulson (conathan)
Location: Alberta, Canada
Timezone: MST (-7)
More information about the lfs-dev