Re: Reporting the Microkernel in the GNU triple?

[Niels Möller]

Roland McGrath <roland@frob.com> writes:

> 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.)

They're special, but not special enough in this context... The reason
is that most programs won't and shouldn't use AC_CANONICAL_HOST at
all, they should just use configure tests for the functions they need,
no matter if the functions are from glibc, hurd, mach or l4.

glibc is an exception in that it *really needs* to use the config
tuple. The point of the config tuple is to provide details on the
systems that most programs won't need. And that's why I think it makes
sense to include information about the underlying microkernel, which
is needed by glibc and a few other packages, there.

(BTW, the CPU component is almost the same; most programs don't need
that information, but of those programs most won't use
AC_CANONICAL_HOST anyway).

> 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 agree with that.

> The kernel-os part of the tuple is something-gnu for any system where glibc
> is the system API, basically.

If you want to match any glibc system, *-gnu should do. Originally, I
guess a gnu system was supposed to be *-*-gnu, but then linux came
along, and that pattern won't match i686-pc-linux-gnu.

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.

After experimenting a little with current config.sub (GNU config.sub
(2003-02-03)), I'm a little confused:

  nisse@carduelis:~/hack/lsh/src/nettle$ ./config.sub i686-gnu
  i686-pc-gnu
  nisse@carduelis:~/hack/lsh/src/nettle$ ./config.sub i686-linux
  i686-pc-linux-gnu
  nisse@carduelis:~/hack/lsh/src/nettle$ ./config.sub i686-pc-gnu-gnu
  Invalid configuration `i686-pc-gnu-gnu': machine `i686-pc-gnu' not recognized

So where is *-gnu-gnu used?

> Do you want to have a separate ABI universe for l4-hurd?

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).

> Do you want Debian to consider l4hurd-i386 a different architecture
> than hurd-i386?

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

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

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.

> 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'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.

/Niels