When compiling arm926ej-s programs, it appears that the resulting ELF headers mark the compilations as VFP as well as software FP. When linking against a generic lowest-common-denominator libc or libgcc, the linker complains the the library modules are built as FPA (also software FP), and the VFP/FPA mismatch produces the error: libc.a(XXX.o) uses FPA instructions, whereas output.elf does not That comes from elf32_arm_merge_private_bfd_data in elf32-arm.c. The common workaround seems to be to add -mfpu=fpa to the compilation flags, and -mfpu=softfpa to the assembler. But it seems to me that two software FP modules should not be declared incompatible because of a mismatch in the kind of floating fp instructions that they _don't_ have.
Quite the contrary. FPA versus VFP controls two different things: which instructions would be used for hardware FP, and what format is used for double precision floats. A little endian FPA target puts the two words in the opposite order of a little endian VFP target. So it's likely that your libraries actually do mismatch and one of the compilers in use is configured incorrectly.
OK, now I understand. According to a comment in the the arm gcc's source, /* For V5 or later processors we default to using VFP; but the user should really set the FPU type explicitly. */ So the fact that users have to add those flags is as-designed. I'll mark this as, I guess, INVALID unless that's the wrong procedure, in which case someone who knows better can change it. Thanks.