Multilib FAQ
From CLFS-HINTS
Contents |
Why would I want to build a multilib system?
This is a question sometimes asked in the CLFS IRC channel. There are several reasons one may wish to build a multilib system. Some of these reasons are discussed below.
Applications Only Available as 32-bit
There are some libraries and applications that are only available as 32-bit. For example, audio codecs, browser plugins, or Adobe Reader. If these libraries or applications are important to you, then you would either need a 32-bit only system or a multilib system.
A pure 32-bit system leaves you in the past as it were. Eventually these 32-bit only libraries will either be supplanted by new technology or offered as a 64-bit version. If you are using a 32-bit only platform, your only option is to rebuild a perfectly good system simply to use the latest Flash plugin. On a multilib platform, you simply remove the old 32-bit Flash library and install the 64-bit version. While there are wrappers that can be applied to use 32-bit plugins with 64-bit browsers, these are unnecessary workarounds to the real solution which is to provide support for both 32- and 64-bit applications, i.e. a multilib build.
x86_64
If you are using an x86_64 machine, then you are using a multilib platform. Technically, there is no such thing as a pure 32-bit or pure 64-bit x86_64 machine. Linux developers that adhere to various standards will develop x86_64 ports as a multilib architecture because these standards require x86_64 machines to provide multilib support. You may find yourself struggling to install certain packages in a pure 32- or 64-bit environment on an x86_64 machine because it is not standards compliant.
Do I always build both 32- and 64-bit applications?
The short answer is no. Look at the CLFS instructions for a multilib build, not every package is built as both. In fact, the majority are only built once. In those cases where both a 32- and a 64-bit version are built, any 64-bit binaries overwrite the 32-bit version anyway. What we are primarily interested in when we build both ABI is the libraries provided by the package.
We would like certain 32-bit libraries to support those few 32-bit applications we plan to use (see question #1). These are really the only packages that need to be built as both 32- and 64-bit. Building everything twice results in a lot of 32-bit libraries laying around not being used. You will find that many, if not most, CLFS multilib users are building everything as 64-bit except a handful of applications like mplayer and Firefox.
What needs to be "wrapped" by the multiarch wrapper program?
Anything that has library paths hardcoded and we have both the 32- and 64-bit version installed. One example is config scripts that are used by other packages to link properly against the appropriate libraries. Let's look at the libpng-config script.
Executing libpng-config to retrieve library directory information results in the following because the 64-bit ABI is the default:
weibullguy@weibullone:$ libpng-config --libdir /usr/lib64
Here is the output of the same command, except we specifically told the config we wanted to know where the 32-bit libraries were installed:
weibullguy@weibullone:$ USE_ARCH=32 libpng-config --libdir /usr/lib
Here it is again being explicitly told to show the location of the 64-bit libraries:
weibullguy@weibullone:$ USE_ARCH=64 libpng-config --libdir /usr/lib64
