Re: Deciding new arm EABI port name
On Thu, Mar 30, 2006 at 11:59:54AM +0100, Martin Guy wrote:
> > "arm", "i386", "m68k" are shorthands. Please have a look at
> > dpkg-architecture sources:
> >
> > if ($os eq "linux") {
> > return $cpu;
> > } else {
> > return "$os-$cpu";
> > }
> >
> > Next, have a look at ostable and cputable files. After that I think it
> > should be clear why current dpkg-architecture limits our choices.
>
> Aha. Thanks.
>
> It does seem that the current Debian structure is creaking at having
> to cram different os-cpu-libc-abi-endian combinations into a single
> namespace ("$cpu" above). What was originally conceived as a way of
> supporting different hardware is now being used to support different
> ways of using that hardware: different "$cpu"s now mean binarily
> incompatible compiled object formats (caused by difference in OS, CPU,
> libc, endianness or ABI).
> The different OS issue has already been split off as "prefix-" to
> support hurd and freebsd.
>
> This may be enough - mipsel and armeb seem to be happy enough - but it
> still seems to me that, within the existing Debian scheme, poking
> [gnu]eabi into the "os" namespace instead of the "cpu" namespace is an
> even stranger choice. It's not as if EABI binaries are os-independent.
>
> At this point it's no longer "just a name", but raises one of two questions:
> - do we need to re-evaluate the whole issue of
> os-cpu-endianism-abi-floatingpointuse-libc, giving unspecified fields
> cpu-dependent defaults (or using shortform alises) that will let the
> existing names continue unmodified?
Isn't FPU something more related to the CPU rather than LIBC or
ABI? If we end up with OS-CPU-LIBC-ABI (where CPU obviously contains
ENDIAN and FPU), then I will be happy enough:-) The issue of having
ABI first and LIBC second is a minor one I think, what looks better
to you: arm-gnu-eabi or arm-eabi-gnu?
> or
> - which of the existing inappropriate namespaces (os or cpu) do we
> hijack to support a new ABI for arm?
>
> M
>
>
Reply to: