Re: Reporting the Microkernel in the GNU triple?

[Roland McGrath]

The actual history is rather convoluted.  I had misremembered what the
current config.sub canonicalization does.  I said it always produced a
4-part tuple, but in fact it produces either a 3-part or a 4-part tuple and
I think in practice it's only 4 parts when the last part (os) is "gnu" and
the third part (kernel) is "linux" or "freebsd".

> I got the impression from rms that the canonical name for the
> current, mach-based, hurd, was *-hurd-gnu, not *-gnu-gnu (see the
> message I referred to earlier), which makes
> sense to me, but you probably know config.{sub|guess} better.

>From those second hand quotes out of context, I don't really know what rms
might have had in mind.  config.sub does not and has never recognized "hurd".
If rms wants it to, he hasn't told the config.sub maintainers.

> So where is *-gnu-gnu used?

It ain't.  If you were to add anything new consistent with what config.sub
has now, it would be of the form *-foo-gnu (and foo shouldn't contain a -).
(That much of what I said was right.)  That is consistent with *-linux-gnu
and *-freebsd-gnu, which are currently supported.  Papa likes us best, so
we (Hurd) get to be plain *-gnu.

> No. I want the same ABI for all of linux-gnu, mach-hurd-gnu and
> l4-hurd-gnu (assuming we're on the same cpu, and talking about
> unixish programs).

Right on, brother!  Well, Jerusalem before Mecca, ok?  Avoiding any schism
among Hurd denominations before it starts is what we can do now.  Bringing
Linux into the holy peace is a longer term goal.

> No. We only need to figure out how to get the glibc (and any other
> packages that depends on the microkernel) packaging right.

That probably belongs on debian-hurd.  

> A predefine might be useful for a few special programs, but not terribly
> important (in particular not if a configure script can pick up that
> information in some other way). A single toolchain is a good thing.

A predefine is harmful if it makes the toolchain distinguish the microkernel.
So we should get rid of those.  I doubt there are many places that use
#ifdef MACH or #ifdef __MACH__, perhaps none in GNU programs.  

> I'm not entirely sure where you're suggesting that information to be
> placed in the config tuple, but to me it seems preferable to keep it
> in the middle, next to the kernel part (hurd), so that *-gnu will
> continue to match all glibc systems.

What matches all glibc systems is *-gnu*, which is to say an OS part of
gnu*.  But it does seem reasonable enough to use the "kernel" part for
these distinctions (in the few places we need to make them).  If config.sub
is made to accept hurd* in the kernel part, that would suffice.  That is
however a bit odd since if we don't want the canonicalization of i386-gnu
to become i386-pc-hurd-gnu instead of i386-pc-gnu.  For uses like the
toolchain, it's the alias you choose that matters (i.e. if you say
--target=i386-gnu you get i386-gnu-gcc et al regardless of the canonical name).
But I am not sure off hand what all out there now expecting the current
canonical name might be broken.