[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian cross infrastructure maintenance proposal

Another try (formatting)...

Alexander Shishckin wrote:

On 4/27/06, Pjotr Kourzanov <peter.kourzanov@xs4all.nl> wrote:
Alexander Shishckin wrote:

On 4/27/06, Wookey <wookey@aleph1.co.uk> 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

 $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

 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.

  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 before 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.


To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: