I am told that the "choice of name" is the one thing that has
generated most heat and least light among the Debian EABIfiers - maybe
because it really doesn't matter, or maybe because it's the only thing
the technically weak feel competent to argue about... ;) Personally I
think "wendy" is a nice name ;)
Rather than choose a soapbox to stand on, I'll suggest a few criteria
for it to fit in with the schemes for existing Debian architecture
variants (there is a list at popcorn.debian.org) and to future-proof
it:
- it begin with something that identifies the processor it runs on
- it be short
- it be composed of lower case alphanumerics (hyphens are currently
used for non-linux kernels such as hurd-i386 and kfreebsd-amd64
- it be unsurprising
- it look to the future for other variants that can reasonably be
expected, such as *eb for a bigendian version if the default is
little-endian or hurd-* netbsd-* for the hurd kernel variant, without
becoming grotesque.
> |update: since dpkg in etch, gnueabi-arm is pretty much the only choice.
> Someone knows what does this mean?
No idea. I searched for some justification of this but found nothing.
The only place the phrase occurs on the net is in a patch to openssl
0.9.7e for openembedded on armeb (!)
It would imply that Debian might reasonably produce gnueabi-i386,
gnueabi-m68k and so on orthogonally with gnueabi-arm. But the only
reason for using a new ABI for ARM is the inadequacies of the existing
one (like, you can't use your hardware FPU!).
Anyway, I always get suspicious when someone says "there is no other way" ;)
An aside to whoever wrote this: please always quote your sources explicitly!
> Is there any plan for armeb to switch to EABI before getting into the archive?
armeb already have a vast repository of compiled binaries at
armeb.debian.net which I assume people are already using in the field
- I can't see them binning the whole thing and starting over, and in
any case that would break every installation already using that
repository.
Good luck!
M
