Re: Reporting the Microkernel in the GNU triple?

[Niels Möller]

Roland McGrath <roland@frob.com> writes:

> > I disagree slightly. I'd say that for most purposes we don't *need* a
> > distinct tuple, which is not quite the same thing.
> 
> I asked before if you wanted one, and I thought you said you didn't.
> If you do, tell me why.

To have a *single* canonical name for the system that works when cross
compiling *all* hurd packages (which support crosscompiling at all),
including the few low-level packages like glibc, hurd and gdb and any
other odd hacks that use the microkernel directly.

I guess your response will be that every package except the Hurd
itself should use configure checks for l4/mach related functions and
header files instead of AC_CANONICAL_HOST? That's fine too, but I
still think it would be useful and reasonable to also have that
information in the configuration tuple.

And then of course there's also an immediate practical problem: Anyone
who starts hacking on L4 sysdeps in glibc or hurd libraries needs to
know what name to use for configuration. That's a practical question
that's been raised several times over the last several months, and
which still needs a good answer.

Let me digress some more to try to motivate the reasonability, I
promise I'll stop soon... This issue isn't crucially important to me,
but I'd really hope I can make myself understood before we leave it.

I compare the microkernel to the cpu part of the tuple. The cpu
provides a "real cpu", while the micro kernel provides an "abstracted
cpu". When compiling from source, most packages need not know anything
about either cpu or microkernel, as libraries and the toolchain hide
the differences. My gut feeling is that when talking about autoconf
issues, the config tuple in particular, this should be all that
matters, the config tuple lives in the build process.

A few exceptional packages will depend on the cpu (gmp, binutils,
...), and different set of exceptional packages will depend on the
microkernel, or "abstract cpu", (the Hurd, hacks implementing things
like persistent or network transparent tasks). And there are also some
really exceptional packages, in particular glibc, that will depend on
both. These are the only packages using AC_CANONICAL_HOST and friends.

You seem to worry about effects on binary distributions ("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?"). Like
I said, I don't want that, but to me these issues seem independent; if
you have a good reason to think that distinct config tuples
necessarily implies distinct system ABI:s, I don't yet understand it.
ABI-names encoded into ELF files should be configured in a way that is
independent of the microkernel part. Almost all packages will be
"microkernel: any" (somewhat analogous to binary-all packages in
debian, although probably implementated differently, as microkernel
independence should be the rule, not an exception). I don't see any
problem here.

Regards,
/Niels