architecture naming discussion
Alexander Shishckin wrote:
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.
well, I am currently playing with these now:
glibc: arm{,v4,v5te}-eabi, strongarm, xscale,
uclibc: arm-uclibc, i386-uclibc and mipsel-uclibc.
and they are all linux, yes, but supposing that one day we will
want to look at uclinux or freebsd I see that the kernel must be
explicitly mentioned since then i386-uclibc (or uclibc-i386 for
that matter) might mean either linux, uclinux or *BSD. And in
that case, the $libc-$cpu order loses since $kernel-$cpu is already
claimed by hurd- and kfreebsd- architectures.
With minor patches to dpkg{,-cross}, config.sub and debian/rules
this is all pretty much workable though...
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).
correct.
Otherwise if it says uclibc-i386, your kernel is linux and libc is
why? the kernel might be uclinux or freebsd.
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: