> 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.
