Hello Martin, 2010/7/10, Martin Guy <[email protected]>: > 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." -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
