Paul Brook wrote:
Do we want to enable more multilibs in arm-elf?
Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
maintenance only mode. You should be using arm-eabi.
IMHO building lots of multilibs by default significantly increases toolchain
size and build time for little actual benefit. ARM CPUs are generally
backwards compatible and we only have one important ABI variant, so very few
multilibs are required for a functional toolchain. Anybody who cares about
optimized runtime libraries probably wants tuning for their exact setup,
rather than whatever arbitrary selections you're going to choose.
We only want to provide one arm-rtems toolset binary and provide
the minimal number of multilibs to support as many ARMs
as possible. So ultimately this will go in arm/t-rtems but I wanted
to see a non-OS target produce hello worlds that would run
with arm-XXX-run. I will switch my testing to arm-eabi. But
it uses the same t-arm-elf for variations.
Since this will be arm-rtems multilib's when submitted,
which variants and matches need to be added so we have
the right libraries for all CPU model arguments. ld is
complaining at least about libc.a mismatches for these variations.
does not use Maverick instructions, whereas a.out does
uses FPA instructions, whereas a.out does not
uses hardware FP, whereas a.out uses software FP
Suggestions welcomed.
I promise this is for arm-rtems. :)
--joel
