Selecting an architecture tuple for the Rumprun toolchain

[Joseph Myers]

On Thu, 9 Apr 2015, Martin Lucina wrote:

> I'm not sure what you mean by "tuples do not distinguish the possible use
> of an emulation environment in which to run code". If by "emulation

A toolchain that builds binaries that run for x86_64 GNU/Linux with the 
normal glibc port and kernel has target x86_64-*-linux-gnu (or 
i?86-*-linux-gnu with -m64 used).  That is the case regardless of whether 
the actual platform on which the binaries are then run is x86_64 
GNU/Linux, or a BSD system which provides support for running unmodified 
binaries using Linux syscalls, or QEMU running on AArch64 GNU/Linux doing 
the same, etc.

Some tools may also support generating object files that can be linked 
into binaries for multiple OSes - for example, ARM EABI tools generating 
objects that only use the C library via the CLIBABI portable object 
interfaces - in that case the tuple used would typically be for a 
bare-metal system (arm-*-eabi) but the objects might be used on many 
different systems.

> > If you would use a different glibc port, would it be meaningful to do so 
> > both for Linux (however Linux is involved in your system) and for NetBSD?
> > If so, it seems you have something like (but different from) 
> > *-*-linux-gnu, and something like (but different from) *-*-knetbsd-gnu - 
> > if both kernels affect the glibc port in some way, the kernel component of 
> > the triplet might need to include both kernel names, or else the OS 
> > component might need to contain one of them.  (I don't recommend treating 
> > the vendor component as semantically significant.)  Thus, you might have 
> > arm-*-linux-gnueabirumprun, or (if multiple rumprun variants each need 
> > their own tools / libc) arm-*-linux-gnueabirumprunxen.
> 
> The last variant in the above paragraph is what we need to distinguish all
> possible tools/libc combinations.
> 
> Why do you not recommend using the vendor component for anything
> significant?  To me it seems the logical place to say "this is a rumprun
> toolchain", plus the result is easier to parse than putting "rumprun" AND 
> "platform" AND "userspace" all in the last component.

The vendor component is typically a company name - used either in cases 
where only one name is normally used (*-sun-solaris*, *-hp-hpux*, 
*-ibm-aix*, etc.), or, for free software systems, for branding purposes if 
at all (*-<company>-linux-gnu*).  Presumably multiple distributors might 
each distribute rumprun tools, branded for that distributor, so 
<cpu>-<company>-linux-gnurumprunxen or <cpu>-<company>-netbsd-rumprunxen 
for example.

-- 
Joseph S. Myers
joseph@codesourcery.com