Those building LFS on x86_64 will face the issue of multilib sooner or later - that is, unless one runs solely 64-bit programs. This is mainly to answer the question "How can I run my 32-bit binary on my 64-bit LFS?"
Currently most of the posts direct one to CLFS and cross-compiling 32-bit libraries/binaries on the 64-bit setup. This is of course the most elegant solution, but those who just want to
run programs would end up with a lot more than they have bargained for. It may be more practical to build a 32-bit LFS separately using the same book version, kernel (and configure options).
The problem: Although the x86_64 kernel will support executing 32-bit binaries, you will find that running "ldd ./myprogram" will tell you that myprogram is not a dynamic executable.
The simplest binary would be a compiled "Hello World" C program. In theory this would depend solely on your C library, namely glibc. Assuming the program name "hello" on 32-bit Ubuntu 8.04
Code:
user@hostname:~$ ldd ./hello
linux-gate.so.1 => (0xb7fc1000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e5a000)
/lib/ld-linux.so.2 (0xb7fc2000)
So clearly we need a 32-bit glibc. On LFS the core glibc libraries are installed to /lib. Your libc.so.6 is a symlink to libc-<version>.so, such as libc-2.19.so on LFS 7.5.
What if we copy libc-2.19.so from a 32-bit LFS and run "ldd ./libc-2.19.so" in the 64-bit environment? Again, it will not be recognized. During compilation, you verified the form of the name of the interpreter as ld-linux-x86-64.so.2. When you run ldd on a 32-bit binary on a 32-bit operating system you will see, for example, ld-linux.so.2. So you will need both, one for 64-bit the other for 32-bit.
Note that running ldd on these ld-linux so's reveals that they are statically linked. So you need not worry about infinite regress. These so's are really symlinks to ld-<version>.so.
So in short, you need two things from your 32-bit installation: libc-<version>.so and ld-<version>.so. On a standard multilib installation you typically have /lib and /lib64. However, barring standards, you can put your 32-bit libraries wherever is convenient. In this example, I'll use /opt/32-bit/lib. In other words, place these two so's in /opt/32-bit/lib.
Next, put the symlink to ld, namely ld-linux.so.2 in /opt/32-bit/lib. Further, put a symlink
to this symlink in /lib. But DO NOT put any symlink to your 32-bit libc in /lib. Instead, write a symlink libc.so.6 in /opt/32-bit/lib [i.e., ln -s /opt/32-bit/lib/libc-<version>.so /opt/32-bit/lib/libc.so.6] and add this directory to your /etc/ld.so.conf; then run ldconfig as root. Remember, run ldconfig - nothing will change until you do.
Also, you may need to recompile your x86_64 kernel. You will need to have
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
in your config. Otherwise you have a truly pure 64-bit kernel that is unaware of anything 32-bit. (Note, newer kernels may also have an option CONFIG_X86_32, which isn't mandatory here.)
Once you do this, you should be able to run ldd on your 32-bit Hello World executable and see it is detected as an executable dependent on the 32-bit glibc with the 32-bit interpreter.
Of course this is the simplest case. You will need to figure out what 32-bit programs you need, their dependent libraries, and place all of them in your /opt/32-bit/ prefix as appropriate, adjust your PATH for the 32-bit binary prefix, and so on, etc. But hopefully this takes some of the mystery out of this concept. Users of other distro's who give the solution "Install 32-bit glibc" never have to realize they have TWO linkers, what the symlinks are, where they go, and so on.
Likewise, you can proceed in reverse manner: You should be able to copy your x86_64 kernel and its modules to your 32-bit installation and boot it up "like nothing happened," provided you have the appropriate hardware, of course. (This can be useful if you want to maintain one "32-bit" installation between newer and older hardware but want 64-bit support where you can have it.) For this, you may need to rename your current /lib/modules/version to something else, provided the compiled kernels have the same name.
