Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)
> The Hurd is IMHO more than just a simple kernel replacement of a glibc-
> based system. Due to its flexibility, other applications like host-os
> subhurds are possible too. Just because it's 'oolitically correct' to
> stick to glibc doesn't mean that we _must_! Other GNU programs are not
> dependent on glibc either (thank goodness!).
Well, I am obviously biased towards glibc because I wrote it. But, libc
and hurd were developed together and intended to go together as part of a
whole GNU system. Funny "host-os subhurd" ideas and so forth are all well
and good, but I don't see why you wouldn't want the system you're using in
that context to be a GNU system.
> Another reason I'm having problems with glibc is very simple: I can't
> figure out how to compile that beast on *BSD systems yet (or BTW any
> non-Linux system) even at all or without _much_ contortions :-( But
Well, you have to port it! Ports exist for Linux and for Hurd, so that's
where you can easily build it. The last time glibc ran on a BSD-like
system was Sun Unix 3.2 on a sun3 in version 1.06. If you want to port it
to current BSD systems, then go right ahead. It is pretty well documented
how to go about it in the libc sources. But I don't think such an effort
has anything whatsoever to do with the Hurd, and I'm not interested in
talking about the details of doing such a port.
> this is just one reason. The main interest here is to
> 1. isolate the ukernel interface of the Hurd from the more generic
> C library so that it can be ported _separately_ and more easily
> to other ukernels or host-os(s).
That is a fine goal. It doesn't have much of anything to do with
trying to use Hurd-code with non-GNU C libraries.
> 2. obtain the hosted sub-hurd at a very low cost (in terms of efforts).
For that goal I don't think this way is going to bring you any joy. The
easiest thing by far will be to port libc and hurd to whatever your context
is in the same way we've talked about porting to some other microkernel.