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 Fri, 10 Apr 2015, Martin Lucina wrote:

> 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
> requirement?

Well, config.sub says MANUFACTURER.  Presumably multiple MANUFACTURERs 
could produce compatible rumprun toolchains (and so put their own 
identifiers in that slot).

> "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
> same.

GNU/Linux distributors are very used to needing such regeneration whenever 
doing new architecture ports (or possibly patching config.sub to exec a 
system copy so it can be patched once and not need repatching for each new 
architecture).  I don't think whether a config.sub patch is needed should 
be a relevant consideration.

Joseph S. Myers

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