Howto: Simple multilib setup for x86_64 LFS
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 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. |
You can follow the CLFS book, but it isn't as up-to-date as the regular books are, but it does work, however, the growing rate of 64-bit software against 32-bit is making less and less usage of 32-bit in a 64-bit environment, especially in UNIX. Because programs built from source (roughly 99% of them) can be built for either 64-bit or 32-bit, maintaining multilib is fickle unless you absolutely need to run things like Steam, Wine, and a few random programs.
CBLFS might be a good place to start as well. |
Well CBLFS hasn't been maintained for few years.
But still useful as a way to path. |
I always used to run a multilib system but havn't done in years and frankly have not come across anything that is 32 bit only that I needed to use, if I need to test software on a different arch type I either use vbox, or increasingly qemu with the binfmt_misc kernel module and chroot into a 32 bit ( or whatever system ) and run it direct.
|
This 32-bit stuff really hit home with me last night. My primary work environment is LFS/BLFS loosely based on the SVN book series. I build a lot more beyond the BLFS packages so I do deviate from the instructions. I don't keep the 32-bit libraries as fresh as I do for 64-bit since the only 32-bit apps remaining are acroread, fpc, wine and some custom things I really do need to make sure they work on a 32-bit target.
The release of LLVM-3.6.0 played havoc with Mesa-10.4.5 since a shared library changed its SONAME. It was trivial to rebuild Mesa for the 64-bit side of my multilib platform. But since the 32-bit libraries had suffered from a case of benign neglect, it was an ordeal to track down all of the dependencies I had failed to keep current to get the 32-bit side back in shape. The lesson is that if you're going to multilib, take the few minutes of extra effort to build the 32-bit stuff when you freshen the 64-bit apps/libs and keep it updated. And by the way, I actually have some really old a.out applications that I still run for a trip down the memory hole. So it's a mixed system of 32-bit and 64-bit ELF peppered with some of those ancient a.out 32-bit cruft. :) |
There are a couple of resources out there:
https://github.com/elkrejzi/system-management https://www.williamfeely.info/wiki/Lfs-multilib |
Quote:
|
Plus most of the programs that are 32-bit only have replacements.
The only one that comes to mind without a replacement is Wine, but then again you do have Wine64, and most Windows software has been cloned out, or running a VM produces better results. The only others that come to mind are a few emulators but there's always MAME/MESS. |
All times are GMT -5. The time now is 02:02 PM. |