Basics of Multilib

On a multi-lib system, compiling new packages from scratch is a bit more complicated than just running ./configure && make && make install. Here are some basic things to remember.

Contents

[hide ]

• 1 Build flags
  • 1.1 CC and CXX
  • 1.2 LD
  • 1.3 PKG_CONFIG_PATH
    • 1.3.1 Creating Metadata Files
  • 1.4 Other environment variables
    • 1.4.1 USE_ARCH
• 2 The ./configure script
  • 2.1 PREFIX
  • 2.2 BUILD and HOST
  • 2.3 Library directories
    • 2.3.1 The package's libraries
    • 2.3.2 Other packages' libraries
  • 2.4 Other options
• 3 Inspecting the Makefile
• 4 Watching the build process
• 5 Making sure the files built are what you wanted
• 6 Launching 32 or 64-bit applications

<script type="text/javascript"> if (window.showTocToggle) { var tocShowText = &quot;show&quot;; var tocHideText = &quot;hide&quot;; showTocToggle(); } </script>

Build flags

The first thing to start with is setting up the flags prior to ./configure scripts.

CC and CXX

You need to set up the compilers using the CC and CXX flags according to the architecture you are building for:

CC="gcc ${BUILD32}"

CXX="g++ ${BUILD32}"

or

CC="gcc ${BUILD64}"

CXX="g++ ${BUILD64}"

 Note: ${BUILD32} and ${BUILD64} set in Bash Startup files

LD

Sets the linker used when building a package. The environment variables LD_BUILD32 and LD_BUILD64 are set in CBLFS Bash Startup Script, 50-multilib.sh as -m elf_i386 and -m elf_x86_64 respectively. These set the linker option -memulation . If the '-m' option is not used (as it is if you use the CBLFS Bash startup scripts), the emulation is taken from the LDEMULATION environment variable, if that is defined. Otherwise, the default emulation depends upon how the linker was configured.

Set it up with:

LD="${LD_BUILD32}"

or

LD="${LD_BUILD64}"

PKG_CONFIG_PATH

Sets the path for pkgconfig to search for metadata (*.pc) files. Metadata files are typically installed in */lib{,64}/pkgconfig, so this variable needs to be set to ensure that the 32-bit paths (*/lib/pkgconfig) are searched for 32-bit information and the 64-bit paths (*/lib64/pkgconfig) are searched for 64-bit information.

Generally, it is sufficient to add as an argument when executing the configure script as follows.

PKG_CONFIG_PATH="${PKG_CONFIG_PATH32}" ./configure 

or

PKG_CONFIG_PATH="${PKG_CONFIG_PATH64}" ./configure

In some situations, it may be necessary to explicitly set the variable before executing the configure script.

export PKG_CONFIG_PATH="${PKG_CONFIG_PATH32}"

or

export PKG_CONFIG_PATH="${PKG_CONFIG_PATH64}"

In this case, the variable should be unset after building and installing the package.

unset PKG_CONFIG_PATH

PKG_CONFIG_PATH32 and PKG_CONFIG_PATH64 are set in the CBLFS Bash Startup File, 10-pkg_config_path.sh.

Creating Metadata Files

Every now and then a package does not provide a metadata file. Fortunately, the metadata file is nothing more than a text file with some information about the package. Here's an example of the 32-bit FFTW metadata file fftw3.pc:

prefix=/usr

exec_prefix=${prefix}

libdir=${prefix}/lib

includedir=${prefix}/include


Name: FFTW

Description: fast Fourier transform library

Version: 3.0.1

Libs: -L${libdir} -lfftw3 -lm

Cflags: -I${includedir}

As you can see, there is nothing exciting or magical about this file and you could easily create your own if a package does not provide one. These should be located in one of the pkgconfig directories specified in your PKG_CONFIG_PATH32 or PKG_CONFIG_PATH64 variable for the appropriate ABI.

Other environment variables

USE_ARCH

USE_ARCH is an exciting new environment variable introduced by the CLFS Team. It is used by the multiarch_wrapper program built in CLFS Section 10.12. Study the code to understand how the wrapper works, it's really quite elegant and simple. By setting the appropriate value for USE_ARCH, the multiarch wrapper program will cause the 32-bit or 64-bit version of the target program to be executed.

This is the reason several programs have the -32 and -64 appended to the programs and/or scripts it installs. For example, the CLN package requires that the configuration information script, cln-config, be wrapped. This is accomplished with the following commands for the 32-bit and 64-bit versions respectively:

mv -v /usr/bin/cln-config{,-32}

mv -v /usr/bin/cln-config(,-64}

Finally, the cln-config script is "wrapped" by the multiarch wrapper.

ln -sfv multiarch_wrapper /usr/bin/cln-config

Thus, when we execute cln-config --libs with USE_ARCH=32, the output is:

-L/usr/lib -lcln -lgmp

The output of cln-config --libs with USE_ARCH=64 is, then:

-L/usr/lib64 -lcln -lgmp

You can see the necessity of wrapping this script since it contains information about the installed location of the CLN libraries. Without the wrapper, programs attempting to build against the CLN libraries would be told to look in /usr/lib even if you were trying to build a 64-bit version! By setting USE_ARCH=64 when executing the configure script, the package you are attempting to build against the CLN libraries will use the cln-config-64 script and find the correct ABI libraries.

The ./configure script

The ./configure script often gives you choices for building a 32-bit or 64-bit package. Run:

./configure --help | less

and take note of options that specify the architecture. Some of them to be on the lookout for are the options that define the host and build and also the libraries directories.

PREFIX

Although not specific to multilib systems, you may want to remember to set up the PREFIX where the package will be installed.

./configure --prefix=/usr

BUILD and HOST

The temporary CLFS system was built using the host triplets "i686-pc-linux-gnu" for 32-bit packages and "x86_64-unknown-linux-gnu" for 64-bit packages. These were used to pass the canonical system type to various configure scripts via the following switches:

--build=build-type the type of system on which the package is being configured and compiled. It defaults to the result of running config.guess.

--host=host-type the type of system on which the package will run. By default it is the same as the build machine. Specifying it enables the cross-compilation mode.

--target=target-type the type of system for which any compiler tools in the package will produce code. By default, it is the same as host.

You may note that once the temporary system was built in /tools and /cross-tools these configure options were no longer needed (with the exception of the 32-bit C library headers). Unless you are planning to use your new CLFS system to cross-compile packages, you will likely never need to pass these options to a configure script.

If, for some reason you don't trust config.guess, you can specify them to the ./configure script:

./configure --build="i686-pc-linux-gnu" --host="i686-pc-linux-gnu"

or

./configure --build="x86_64-unknown-linux-gnu" --host="x86_64-unknown-linux-gnu"

Library directories

You want to clearly need to separate the 32-bit libraries from the 64-bit ones.

The package's libraries

By default, autoconf generated configure scripts will place a package's libraries in <prefix>/lib. Thus, when building the 64-bit version of a package, you need to override this default by telling the configure script to install libraries in <prefix>/lib64.

./configure --libdir=/usr/lib64

Other packages' libraries

If the package depends on other libraries to be built and you are using pkgconfig, setting the PKG_CONFIG_PATH variable as above will generally ensure that the configure script finds the correct libraries. Rarely is it necessary to explicitly pass the path of dependent libraries. If you find that this is necessary more often that not either you aren't using pkgconfig or something is wrong with your system.

Other options

Some packages have other options that you may want to specify. For example, the package linuxwacom has these options:

--enable-xserver64

--with-arch=<32 or 64>

Inspecting the Makefile

It is always a good idea to inspect the Makefile and make sure that everything was set up properly. Things to watch out for are other variables that may need to be set prior to running ./configure and if the "install" target will place everything in the right place (i.e. libraries in the lib or lib64 directories).

Watching the build process

During the "make" step, there is usually a lot of output giving us information as to what the make program is currently doing. It is a good idea to inspect the output and make sure everything is according to plan. For example, if you see a program running "gcc" without the -m32 or -m64 options, chances are you have forgotten to specify it before running ./configure scripts or that the flags might need to be specified even when running make.

To do: Is there a way to slow down the output (without necessarily logging it) in order to inspect it non-intrusively (i.e. the make process continues its course, the output is only slowed down for the user to read, even though the screen may not be in sync with the make output).

Making sure the files built are what you wanted

To do: Explain how to use ldd and file to determine the resulting files are 32 or 64 bit and are using the right libraries, maybe even create a script for automating the task a bit.

Launching 32 or 64-bit applications

On a multilib CLFS system, differentiating between the 32-bit and the 64-bit application can be accomplished in several ways. The first is to simply call the 32-bit or 64-bit version explicitly. For example, let's say you built and installed a 32-bit and a 64-bit version of Octave . To use the 32-bit or 64-bit version respectively, you would execute:

octave-32

or

octave-64

The other option would be to use the USE_ARCH variable, in which case the commands would be:

USE_ARCH=32 octave

or

USE_ARCH=64 octave

<!-- NewPP limit report Preprocessor node count: 19/1000000 Post-expand include size: 0/2097152 bytes Template argument size: 0/2097152 bytes Expensive parser function count: 0/100 --> <!-- Saved in parser cache with key mediawiki_hintsdotclfsdotorg-hints:pcache:idhash:24-0!1!0!!en!2!edit=0 and timestamp 20091010020718 -->

Retrieved from "http://hints.cross-lfs.org/index.php/Basics_of_Multilib "

Category : Multilib