> Excellent! I knew this was true for regular GNUMach, but I wasn't sure > if oskit-mach was the same or produced files that had to run either on > the target or the host. This will help me alot.
Just like gnumach, oskit-mach builds one final result: an ELF multiboot kernel. The oskit just provides a bunch of ELF libraries and object files that get linked with oskit-mach's own code to build the kernel. That's all there is to it. The only things that get linked into gnumach and oskit-mach that are provided by whatever build environment you use (aside from the oskit installation, in the case of oskit-mach), are a small set of routines that are purely machine-dependent and not OS-dependent, things such as memcpy and strcpy. The aspects of the ABI that matter for these few things are the same for all ELF/x86 platforms, so just about any library will do. These are linked in from the build environment's standard C library (in both gnumach and oskit-mach): when using native tools, the native libc (a native glibc on either Linux or Hurd is fine, as is the native library on current ELF-based BSD systems such as FreeBSD >= 3.x); when using a normal GNUish cross-tool setup, whatever library you have installed in the cross-compilation environment (i.e. in /usr/i586-gnu/lib or whatever); when using the oskit's x86-oskit-gcc wrapper script (a cheap substitute for a real cross-tool arrangement that gets by ok for building oskit kernels), the oskit's "minimal" C library -loskit_c; when using `x86-oskit-gcc -posix-oskit', it'll be the oskit's version of the freebsd C library (-loskit_freebsd_c). They'll all work, but of these glibc's routines are the best optimized by far last I knew (and some of these are used in core places in the kernel where every cycle counts). Personally, I use the same cross-compilation environment for oskit, libc, hurd, and both microkernels, just to keep it uniform and simple for myself. But if you are just compiling oskit and/or the microkernel(s), then I'd go with simple native tools instead. (In the case of the oskit, building native on linux or freebsd also gives you the "oskit-on-unix" support, which is not of any use with mach, but is nice for playing with little oskit things in general.) Note that there is a debian binary package for (linux) x86 of the last oskit snapshot (though I don't know what compiler Ed built it with). The oskit is a big old beast to compile (it's your usual painless GNUish configure/make deal, it's just a huge mother), so you might not want to deal with it unless you really want to hack on the oskit and want -g symbols in it and so forth. Since all the drivers are in the oskit, oskit-mach is pretty small and quick to compile once you have the oskit installed.
