This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Selecting an architecture tuple for the Rumprun toolchain

On Thursday, 09.04.2015 at 16:20, Joseph Myers wrote:
> > 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.

You say "typically a company name", presumably that is custom but not a

Based on our discussion the options are:

1) *-*-netbsd<variant>-rumprun<platform>
2) *-*-netbsd<variant>rumprun<platform>
3) *-rumprun<platform>-netbsd<variant>

<variant> is a subarch/ABI specifier such as "eabi", "sf".

"2" and "3" have the advantage of working with existing config.sub scripts
out of the box. "1" would require submitting a patch to autoconf and, until
upstream packages regenerate their build scripts using the new autoconf,
that we run autoreconf before building software in order to get the new
config.sub. This would also mean instructing end users/porters to do the

Between "2" and "3" my preference would be for "3", hence my question about
how strong the requirement to not use the vendor name for our purposes is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]