Re: arm-elf multilib issues

[Paul Brook <paul at codesourcery dot com>]

> 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

Either the errors are genuine, or your toolchain is misconfigured. It's common 
for old binutils to use different defaults to gcc.

Like I said before, switch to an EABI based toolchain and you shauldn't have 
any problems[1].  We have a proper object attribute system there, with 
corresponding directives for communication between compiler and assembler.

This can't be a new problem, and I have no sympathy for anyone inventing new 
code/targets that are not EABI based.

Paul

[1] Maverick support may be a bit busted because noone's bothered defining or 
implementing the appropriate EABI bits, but AFAICT the maverick code has 
always been fairly busted so you're not really loosing anything.