Re: armelfp: new architecture name for an armel variant
Hello Martin,
2010/7/10, Martin Guy <martinwguy@gmail.com>:
> What are the effects of the name choice?
If we pick up the wrong name, then we would need to start over the
bootstrapping again, and we would like to avoid that.
> Is it really just a matter of personal taste?
For the Debian architecture name, I believe that is, we need patching
everywhere needed anyway.
> Can we just as well call it "sprongly"? Or is, for example,
> "armsprongly" more likely to give less grief? Or is "armelsprongly"
> even better? This depends on the patterns recognized by existing
> config and build scripts.
Usually either the config/build scripts should rely on
`dpkg-architecture' and it would be worth to patch the ones that are
not or they have hardcoded names (as toolchains) which have to be
patched anyway.
> From the EABI port I remember build files being changed to recognize
> the tuple "arm*-linux-gnu*", hoping to future-proof themselves, so
> that would seem wise to follow.
The tuple part, according to upstream, it should be
'arm-linux-gnueabi'; then build with arm multilibs enabled. If I am
correct, it is at the moment, just a distro thing we need to carry on
and upstream code (toolchain) leave us with the following cases:
==> i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
arm*-*-netbsdelf*) ;;
sh*-*-pe|mips*-*-pe|*arm-wince-pe)
arm-semi-aof )
arm-*-coff | strongarm-*-coff | xscale-*-coff)
==> arm-*-elf* | strongarm-*-elf* | xscale-*-elf* | arm*-*-eabi* )
==> arm*-*-linux-gnueabi)
arm*-*-symbianelf*)
arm-*-pe*)
arm-*-riscix*)
mips*-*-pe | sh*-*-pe | *arm-wince-pe)
> I also remember "debian-arch =~ arm*" being used in some cases, again
> suggesting as arch name that starts with "arm"
I had look in a small amount of packages from base and I could not
find any reference to this string you are suggesting. In anyway, this
is wrong and should use `dpkg-architecture'. Could you find a case
where this happens (please avoid toolchain packages)?
> If the name really is totally arbitrary, I'd suggest using something
> that reflects with as much precision as possible, the target of the
> port, such as
> "armv7", "armvfp" "armvfp3". That leaves the gate open to future neon
> ports, vfp4-32 ports, thumb2 ports and (gak!) maverick ports, without
> asserting that in all cases fp means vfp means vfp3-16
I would suggest small charset for faster coding :-)
> There is another technical question WRT the triple: that is be a valid
> GCC configuration triple, for which, in FOO-linux-gnueabi, FOO be a
> valid argument of the "-march=" flag. It would be well for the vendor
> string to correspond to whatever the compiler returns as a version
> string, though I understand that it really needs to corrispond to
> arm-*-linux-gnueabi
FOO as CPU I assume. Our lovely friend Raúl Porcel (armin76) maintains
a good set of arm optimized architectures variants [1][2] in Gentoo
distribution. Would that be the case?
Best regards,
[1] http://dev.gentoo.org/~armin76/arm/specs/
[2] http://mirrors.kernel.org/gentoo/releases/arm/autobuilds/current-stage3/
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
Reply to: