This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: arm-elf multilib issues
> 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.