Re: Debian cross infrastructure maintenance proposal

[Pjotr Kourzanov <peter.kourzanov@xs4all.nl>]

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

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

 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
> > uclinux-arm-uclibc?
> >    
> 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.

Pjotr.


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