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