Re: Debian cross infrastructure maintenance proposal
On 4/27/06, Pjotr Kourzanov <peter.kourzanov@xs4all.nl> 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.
Reply to: