Re: Debian cross infrastructure maintenance proposal
Alexander Shishckin wrote:
$os is always a combination of the $kernel, $libc and $abi (calling
Almost always, the $abi is fixed for a given $cpu, so that is implicit
(ARM EABI being
On 4/27/06, Pjotr Kourzanov <firstname.lastname@example.org> wrote:
Alexander Shishckin wrote:
On 4/27/06, Wookey <email@example.com> wrote:
Yes. It is in the recently uploaded 2.16.1cvs20060413-1 so we can stop
carrying that, and next try to push the -uclibc architectures in (althogh
people need to agree which set of patches to push and the names (uclibc-i386
or i386-uclibc for example - patches for both exist). This is part of the
general 'arch-naming' debate we have been having. I'm not sure if a clib
naming convention has been agreed?
binutils package has little to do with architecture naming, although,
I've never seen or heard of cross toolchains supporting this $cpu-$os
scheme. And honestly, I haven't seen even patches against dpkg to even
allow for such weirdness (and break compatibility with debian ports).
Yes, it should remain $os-$cpu. Which brings up the question of why
do you mix $os with $libc? Shouldn't uclibc-i386 then really be i386-uclibc
It has been several times discussed, and I'm strongly of this opinion
that $libc may well be considered $os. Don't differentiate between
a notable exception).
But OK, let's make a matrix (to my knowledge, please correct:-)
hurd freebsd netbsd openbsd
x x x? 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.
To maintain compatibility with older names such as hurd-i386 it was
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.
Also, having $cpu in between $kernel and $libc can help in disambiguating
between those. dpkg (-cross) tools would then just need to find a correct
$cpu (as listed in /usr/share/dpkg/cputable) and check that whatever is
that is a correct $kernel and whatever is after that is a correct $libc
(by checking that
$os=$kernel-$libc is listed in /usr/share/dpkg/ostable).
If you really want to bring up architecture topic, think of the good
'ol arm eabi, then think of softfloat vs hardfloat for different
architectures. But let's move this to another thread.
(or, in full, linux-i386-uclibc)? How would you approach debianizing the
following GNU_TYPE: arm-uclinux-uclibc, which IMHO could best be named
Doesn't uclinux imply uclibc? (and who actually cares about uclinux here?)
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.
Not many people now use uclinux but it is still an important *embedded*
thing, so I wouldn't exclude it right from the start.