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

Re: architecture naming discussion



On 4/27/06, Pjotr Kourzanov <peter.kourzanov@xs4all.nl> wrote:
> 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.
I thought 3/4 of these kernels are pretty mouldy and/or starting to smell.
But anyway, it would be great if finally someone ends up with a
complete implementation of this idea. I'll be having hard times
merging those with what I have now, but that's solely my problem.

What this approach does not solve is this (mentioned a couple of mails
ago): how do I fit ARMs and fpu-enabled ARMs in this scheme? Those are
clearly two different architectures. And I can imagine a dozen of such
rather minor but pretty unpleasant things. I would trade any
hurd/uclinux/openbsd stuff for a proper solution to this problem.

> With minor patches to dpkg{,-cross}, config.sub and debian/rules
> this is all pretty much workable though...
Undoubtedly.

> >Otherwise if it says uclibc-i386, your kernel is linux and libc is
> >
> >
> why? the kernel might be uclinux or freebsd.
Ah, but you forgot that I take linux for the default kernel. :)

--
I am free of all prejudices. I hate every one equally.

Reply to: