This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Selecting an architecture tuple for the Rumprun toolchain
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Lucina <martin at lucina dot net>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 10 Apr 2015 20:11:27 +0000
- Subject: Re: Selecting an architecture tuple for the Rumprun toolchain
- Authentication-results: sourceware.org; auth=none
- References: <20150330142356 dot GE7411 at nodbug dot moloch dot sk> <alpine dot DEB dot 2 dot 10 dot 1504021610540 dot 27469 at digraph dot polyomino dot org dot uk> <20150409152406 dot GI31753 at nodbug dot moloch dot sk> <alpine dot DEB dot 2 dot 10 dot 1504091609420 dot 26149 at digraph dot polyomino dot org dot uk> <20150410110051 dot GI1464 at nodbug dot moloch dot sk>
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
joseph@codesourcery.com