On 4/27/06, Pjotr Kourzanov <[EMAIL PROTECTED]> wrote: > $os is always a combination of the $kernel, $libc and $abi > (calling conventions). Almost always, the $abi is fixed for a > given $cpu, so that is implicit (ARM EABI being a notable exception). > > But OK, let's make a matrix (to my knowledge, please correct:-) > > linux uclinux hurd freebsd netbsd openbsd > glibc x x x x? x? > uclibc x x x? x? x? > diet x > newlib x > freebsdlibc x > netbsdlibc x > openbsd libc x > > So, apparently it is not quite that simple to just say that > $os=$libc since as you see, the $kernel is also a distinguishing > factor. In real world, the need to expicitly mention kernel is really rare. It's nice to have all these variations of kernels and c libraries in one distribution, however, emdebian haven't got so far as to have linux+glibc properly (with one exception), so let us leave hurd and openbsd support for now.
> To maintain compatibility with older names such as hurd-i386 it was > suggested to name new architectures according to $kernel-$cpu-$libc > with $kernel=linux and $libc=gnu implied as usual. And this results > in i386-uclibc, *not* uclibc-i386. Excuse me, it doesn't result in anything at the moment. Correct me if I'm wrong, but the only implementation of uclibc targets as of today is slind. > It does, dut you dont say uclinux-i386, you say uclibc-i386 and > *that* does *not* imply "uclinux", because, as you see, "uclibc" > is also supported on "linux" and may be, or already is supported > on *BSD's. If your architecture says uclinux-i386, it means one and only thing that your libc is uclibc and your kernel is uclinux (and not linux). Otherwise if it says uclibc-i386, your kernel is linux and libc is uclibc. No problem here. P.S. Once again, let's move architecture-related discussions from this thread. -- I am free of all prejudices. I hate every one equally.
