Re: Reporting the Microkernel in the GNU triple?

[Roland McGrath]

> Then how should glibc be configured when built for Hurd on L4? glibc
> needs to know if it should use l4 or mach sysdeps, right? Let's also
> assume it's cross compiled, to rule out some other means for testing.

Right.  But the theory (mine anyway) is that it is only libc, hurd, and
maybe a couple of other special cases that need to think about this level
of things.  We can consider them individually once we agree that they are
special cases.  (The other one that comes to mind atm is native gdb.)

The reason I say they are special cases is because most of the system
should not distinguish.  glibc and the various Hurd libraries are what
constitute the OS interface.  The microkernel is an implementation detail.
I realize things are a bit far from this at the moment, but I think we can
and should close that gap rather than doing anything to make it easier for
it to widen.

The kernel-os part of the tuple is something-gnu for any system where glibc
is the system API, basically.  The something can't contain another - or
various scripts will probably be confused.  So we have one word.  The GNU
project made a decision a long time ago that GNU/Hurd is "the GNU system"
and gets called "gnu" (rather than "hurd") in the configuration tuple.  To
be honest, I don't personally care if it's called "i386-pc-fred-gnu", but
we have the current canonical i386-pc-gnu-gnu well established already.

Of course, nothing prevents the l4-hurd project from choosing a new tuple
*-*-l4hurd-gnu and getting that accepted as canonical by config.sub,
binutils, gcc, etc.  (In fact, I have some binutils patches to unify all
cpu-*-*-gnu as the same ELF targets, i.e. what's now written to match
cpu-*-linux-gnu* | cpu-*-gnu-gnu*.  If we dusted that off and got it
integrated, you wouldn't have any new work specific to your new tuple in
binutils.)  I certainly wouldn't discourage any other maintainers from
accepting such changes if you were intent on making them.

But that's not what I want.  Do you want to have a separate ABI universe
for l4-hurd?  Do you want Debian to consider l4hurd-i386 a different
architecture than hurd-i386?  Do you want separate toolchains and different
gcc predefines?  I don't want those things.  I want the single "cpu-gnu"
toolchains (gcc and binutils) to be right for both.  

If whatever os-sensitive things are careful to use wildcard patterns -gnu*,
then we can leave those alone and have the cases like libc and gdb look for
-gnumach* vs -gnul4* or something like that.

I am willing to be talked out of anything I've said about this.  My
leanings have to do with a vision about how we like to think about the
future Hurd system, more than a pragmatic interest in deploying a distinct
new l4hurd system on its own as quickly as possible.