Re: cross compilation tool versions
> 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.
Reply to: