Gentoo Policy demands all shared objects to be compiled with
CFLAGS. Since this is only a rule, you can break it on some arches.
You might never notice it. On AMD64, this is a necessity, if shared objects aren't
built with support for position independent code, the build process bails out
with an error message like this:
foo.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
There are several ways to enforce
-fPIC on shared objects, each with its
pros and cons.
Sometimes, a simple
sed command is enough to fix it, however, the statements
normally aren't very readable and may fail when upstream changes the file.
Please verify that you only change the
CFLAGS for shared objects, not for
the whole package.
Do not patch the
Makefile itself, since it is usually generated by the
configure script and may vary heavily, so the patch could fail. Also, this
doesn't help upstream at all.
Another bad idea is to (ab)use
append-flags function from
-fPIC on all objects should not be done. It should only be
applied to shared objects.
The current AMD64 processors are able to natively run 32bit code on a 64bit
kernel. Therefore, you can run programs compiled for x86 in an amd64 environment.
However, 32bit applications need to be linked against 32bit libraries. Mixing
them won't work. For this reason the libraries are sorted, 32bit libraries normally
/usr/lib32, the 64bit ones normally to
/usr/lib64. In a perfect world, you wouldn't have to read on. Unfortunately,
that's not the case, and so it's a bit more complicated.
To generate 32bit code, we need a multilib-capable GCC. On other architectures,
this functionality is enabled with the USE flag
multilib. This is also true
for amd64 with the pre-2005.0 profiles. From 2005.0 on, you have to choose
whether you want multilib support or not by selecting the profile. Choose
2005.0/no-multilib if you don't want it, all other profiles have the
multilib USE flag masked, you're forced to it. With these profiles, GCC will
produce x86-code whenever you add
-m32 to its command line. Adding
or omitting any bit-width option will default to producing 64bit code.
If you've chosen a multilib profile, glibc will be built twice, once 64bit and once 32bit. This is because nearly every application links against glibc. To understand how this is done in the ebuild, read The ABI Variable.
As you read above, 32bit applications must be linked against 32bit libraries.
For that, we've made the most common libraries as multilib (via
Currently, we provide several profiles, each with its own combination of
libdir configurations. Table entries x86, amd64, etc. indicate that
the directory contains objects for this ABI; entries with an arrow indicate
a symlink to the respective directory.
To always get the right path, you should use
$(get_libdir) which is
available as a package manager function since EAPI 6. It will always return
the correct directory, on all arches. And of course it also takes care of
Many Makefiles assume that their libraries should go to
$(prefix)/lib. This assumption can cause a serious mess if
isn't a symlink to
/usr/lib64. To find the bad packages, we have a Portage feature
called multilib-strict. It will prevent emerge from putting 64bit libraries
into anything other than
multilib-strict currently doesn't check perl5, gcc, gcc-lib and eclipse-3,
this behaviour is controlled by the
MULTILIB_STRICT_EXEMPT variable in
In most cases, default
econf behaviour is sufficient, because it will
pass the correct
--libdir option to
Some packages provide really bad Makefiles which hard-code
sed -ed or patched. Don't forget to let upstream know about your
Most C/C++ programs need standard header files like
types.h. Some of them
depend on architecture specific facts, e.g.
types.h on the length
of machine words. To ensure that we can compile both 32bit and 64bit
applications and libraries, we treat
/usr/include/asm a bit special.
This is what
/usr/include/asm/types.h looks like on an AMD64 box:
/* Common header file autogenerated by create_ml_includes in multilib.eclass */ #ifdef __i386__ #include <asm-i386/types.h> #endif /* __i386__ */ #ifdef __x86_64__ #include <asm-x86_64/types.h> #endif /* __x86_64__ */
As you can see, this is just a wrapper that decides which file you need
depending on the parameter
-D given to gcc. You'll probably run into
some troubles if you try to compile something by hand and forget to append
-D__x86_64__ to your
CFLAGS. Of course, this is not necessary when
using Portage. For an explanation, see the The ABI Variable
Whenever Portage builds something on amd64, it has to decide whether it should
be 32bit or 64bit. As stated in Headers and Multilib
__x86_64__ respectively, is needed in
Also, gcc has to know what code it should produce, therefore
must be appended to CFLAGS. This is done via
profile.bashrc. All you need to do
if you want to build a package 32bit is to set
The details are shown in
MULTILIB_ABIS="x86 amd64" DEFAULT_ABI="amd64" CFLAGS_amd64="-m64" LDFLAGS_amd64="-m elf_x86_64" CHOST_amd64="x86_64-pc-linux-gnu" CDEFINE_amd64="__x86_64__" LIBDIR_amd64="lib64" CFLAGS_x86="-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" LDFLAGS_x86="-m elf_i386 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" CHOST_x86="i686-pc-linux-gnu" CDEFINE_x86="__i386__" LIBDIR_x86="lib32"
On AMD64, some types differ in size from x86:
|Type||x86 (ILP32)||amd64 (LP64)|
||1 byte||1 byte|
||2 bytes||2 bytes|
||4 bytes||4 bytes|
||4 bytes||8 bytes|
||8 bytes||8 bytes|
||4 bytes||8 bytes|
||4 bytes||4 bytes|
||8 bytes||8 bytes|
||16 bytes||16 bytes|
If you need an exact amount of space, don't use these types but the
sXX ones provided by
types.h, where XX is the number of bits you need.
Switching to a type that is the same on both arches is not suggested since it's
not a clean solution and might cause problems with other arches.
Many upstream developers assume that the length of a pointer is 4 bytes, which
can cause problems when programs do casts from
void * to
int and vice
versa. With GCC 3.4, this causes warnings, the compilation won't abort. If
you're lucky, your package works, but it's likely that you encounter
segmentation faults or strange behaviour. GCC 4.0 refuses to compile such code.