[U-Boot] Some ARM builds fail due to float ABI mismatch

[B.R. Oake]

Hello,

If I build U-Boot natively on an A20-Olinuxino-Micro (sunxi) running
Debian Jessie armhf, and the code includes certain operations such as
division of a long long, I get this error:

$ make
[...]
  LDS     u-boot.lds
  LD      u-boot
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o)
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o)
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o)
Makefile:1075: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
$

I think this is because U-Boot has been built with the soft-float ABI,
whereas my system only has a hard-float library.  The relevant build
option is set in arch/arm/config.mk:

PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
      $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))

The build works once I've removed the -msoft-float option.

Would it be possible to refactor the configuration under arch/arm/ so
that this option is not set for the platforms that don't need it?

There was a brief discussion of this issue on the linux-sunxi mailing
list suggesting it may have worked better in the past:

On 28/12/14 16:15, Chen-Yu Tsai wrote:
> It seems some recent changes in upstream broke building with hard float
> toolchains. Best use soft float.
>
> It's probably these commits:
>
> bf1af3d ARM: merge commonly-defined PLATFORM_RELFLAGS
> 3102274 ARM: refactor compiler options in config.mk

( https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg09271.html )

Thanks very much,
B.R. Oake.