Does a list of all known target triplets in use exist?

Question

When cross compiling tools, you will often have to provide "a target triplet". Example given

• i686-pc-linux-gnu
• arm-none-linux-gnueabi
• powerpc-unknown-linux

and so on...

These triplets, which are sometimes in fact four components, have the following form:

<CPU>-<MANUFACTURER>[-<KERNEL>]-<OS>

Kernel is optional and manufacturer can be something like "unknown" or "none", since it is often not relevant.

What I haven't found yet is a page that documents all possible values to be used here. I know that all components are pretty much "free style", so there is no official standard that would force you to use components from an official standardized list. Yet tool designers and configure script writers expect users to specify those triplets to their tools/scripts, so they must have some possible values in mind and there ought to be something like an "unofficial list" tool makers, script writers and users can use as a reference.

Has anyone ever found such a list?

Answer 1

Yes, there is in the libtool sources. It's called PLATFORMS. It's probably not complete. There's also a file called config.sub that gets generated when autoreconf is run. Those are probably more up to date/complete.

But by definition, what you are asking for seems kind of impossible. If there's a new 'xyz' CPU that some manufacturer rolls out it's not going to appear on the list for a time.

So what's a configure script writer do in that case? My solution is the following. I have autoreconf called in a script called bootstrap.sh that sets up a few things before the build as advocated by the Goat Book folks. This script uses sed (well, technically the sed wrapper script in GNU shtool) to insert what I need into config.sub after autoreconf copies it to AC_CONFIG_AUX_DIR.

Fortunately, config.sub files are timestamped so if/when 'xyz' is added to the "official" list you can just test the timestamp. Then you'll add the new "official" config.sub to your tarball and use bootstrap.sh to test if autoreconf is writing a recent enough config.sub. If it's not a recent enough, copy over the old one with the new one.