The GNU config project
exists to take all known systems out there and generate a short string which
describes all relevant aspects (from a toolchain/build perspective) of a system
The canonicalized form is:
machine-vendor-kernel-operating system. Many tuples
may actually omit the vendor field (since it is completely arbitrary). The
operating system field has also expanded its meaning over time to
indicate the userland and/or userland ABI.
Here is a (by no means complete) table of many common configurations. Note
that not all permutations will work as some fields (like kernel or
operating system) imply someone has actually ported the relevant
machine to it which may not be the case.
arm / armeb
avr / avr32
hppa / hppa1.1 / hppa2.0 / hppa64
i386 / i486 / i586 / i686
mips / mipsel / mips64 / mips64el
nios / nios2
powerpc / powerpc64
sparc / sparcv8 / sparcv9 / sparc64
s390 / s390x
sh / sh3 / sh4 / sheb / sh3eb / sh4eb / sh64
mingw32 / mingw64
Remember that part where we said the vendor field was completely
arbitrary? That's almost completely true. In the Gentoo world, we've
allocated the field softfloat to indicate softfloat toolchains. If
you need a softfloat toolchain, make sure to set the vendor field in your
tuple with this in it.
When you use elf as the operating system, you're actually saying you
do not want to run an operating system at all, but just some code directly
on the hardware. This is almost exclusively accomplished with newlib (with
help from libgloss).
The uclinux field produces FLAT binaries which run on Linux with the
MMU disabled (so called no-mmu).
The gnu field indicates glibc as the system libc.
The eabi suffix will work on only a few embedded architectures (arm
and ppc at the moment). This tells the toolchain to generate code for the
newer Embedded ABI.
The uclibc field indicates uClibc as the system libc.
Some quick examples of bringing it all together. Say you want to run a glibc
environment under Linux on a SuperH4 machine. The tuple there would simply be:
sh4-unknown-linux-gnu. Or perhaps you'd like to run some code directly
on the hardware (no operating system) with an arm processor. The tuple there
would be: arm-elf.
While in many cases, the value portage uses for ARCH and KEYWORDS
matches the value used by the kernel, this is not always the case. It also
does not match exactly the machine list in the table above. Over time, the
kernel may even rename/unify some architectures, so an exact list is not
possible without tracking every version!
To find the current list of architectures, simply peek in the arch
subdirectory of your kernel sources. Keep in mind that the kernel will have
many processors unified under a single architecture. So while you may have an
omap or strong arm or xscale processor, these cpus are all part of the same
arm architecture. The same goes for i386, i486, i586, and i686 processors.
These all fall under the i386 architecture.