Thomas Petazzoni, could you shine your light on this patch?
Copy/pasted here for convenience:

diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index faa9d90..c41d757 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -284,8 +284,8 @@ check_arm_abi = \
 		echo "External toolchain uses the unsuported OABI" ; \
 		exit 1 ; \
 	fi ; \
-	EXT_TOOLCHAIN_CRT1=`LANG=C $${__CROSS_CC} -print-file-name=crt1.o` ; \
-	if $${__CROSS_READELF} -A $${EXT_TOOLCHAIN_CRT1} | grep -q "Tag_ABI_VFP_args:" ; then \
+	EXT_TOOLCHAIN_LIBM=`LANG=C $${__CROSS_CC} -print-file-name=libm.so` ; \
+	if $${__CROSS_READELF} -A $${EXT_TOOLCHAIN_LIBM} | grep -q "Tag_ABI_VFP_args:" ; then \
 		EXT_TOOLCHAIN_ABI="eabihf" ; \
 	else \
 		EXT_TOOLCHAIN_ABI="eabi" ; \

Patch resubmitted to the list: http://patchwork.ozlabs.org/patch/320459/
Discussion started, but needs followup.

Investigated it further: there are no problems when eglibc is used, only with uclibc.

A grep for 'hard' or "EABI" in the uclibc-0.9.33.2 sources shows nothing relevant, so I assume eabihf is not supported by uclibc.

(In reply to comment #3)
> Investigated it further: there are no problems when eglibc is used, only with
> uclibc.

Correct.

> 
> A grep for 'hard' or "EABI" in the uclibc-0.9.33.2 sources shows nothing
> relevant, so I assume eabihf is not supported by uclibc.

I don't think the C library needs anything to "support" eabihf. eabihf is all about a change in the calling convention of functions taking floating point arguments.

I haven't got the bottom of this problem yet, but I have indeed reproduced it, and I continue to believe that the fix is *not* to change the external toolchain check, but instead to investigate *why* the uClibc crt1.o does not have those flags when built with the internal toolchain backend.

> 
> the fix is *not* to change the external toolchain check, 

Yes, the patch should not be applied.

command line for crtl1.o looks like this:

$ /opt/testgcc4.8.2/usr/bin/arm-buildroot-linux-uclibcgnueabihf-gcc -c libc/sysdeps/linux/arm/crt1.S -o lib/crt1.o -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -mlittle-endian -fno-stack-protector -nostdinc -I./include -I./include -I. -I./libc/sysdeps/linux -I./libc/sysdeps/linux/arm -Os -funit-at-a-time -fmerge-all-constants -fstrict-aliasing -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -DHAVE_FORCED_UNWIND -I./libpthread/nptl -I./libpthread/nptl -I./libpthread/nptl/sysdeps/unix/sysv/linux/arm/ -I./libpthread/nptl/sysdeps/unix/sysv/linux/arm -I./libpthread/nptl/sysdeps/arm -I./libpthread/nptl/sysdeps/arm -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/pthread -I./libpthread/nptl/sysdeps/pthread/bits -I./libpthread/nptl/sysdeps/generic -I./ldso/ldso/arm -I./ldso/include -I./libc/sysdeps/linux/common -I/opt/testgcc4.8.2/usr/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/ -isystem /opt/testgcc4.8.2/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabihf/4.8.2/include-fixed -isystem /opt/testgcc4.8.2/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabihf/4.8.2/include -DNDEBUG -D__USE_STDIO_FUTEXES__ -MT lib/crt1.o -MD -MP -MF lib/.crt1.o.dep -D__ASSEMBLER__ -Wa,--noexecstack    -DL_crt1

(In reply to comment #4)

> I haven't got the bottom of this problem yet, but I have indeed reproduced it,
> and I continue to believe that the fix is *not* to change the external
> toolchain check, but instead to investigate *why* the uClibc crt1.o does not
> have those flags when built with the internal toolchain backend.

The attributes are added by the compiler, not the assembler. glibc has both c and assembler source for crt1.o while uclibc has only assembler source.

Config file for toolchain:
BR2_arm=y
BR2_cortex_a8=y
BR2_ARM_EABIHF=y
BR2_ARM_FPU_VFPV3=y
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_BINUTILS_VERSION_2_24=y
BR2_GCC_VERSION_4_8_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_ENABLE_LOCALE_PURGE=y
BR2_ENABLE_LOCALE_WHITELIST="C en_US de "


I can indeed confirm that uClibc builds crt1.o from crt1.S, using the command line as specified in comment #7.

Looking in the binutils sources (that creates the assembler), I do find references to ABI_VFP, but I don't see places where it is actually emitted in the build, unless the source assembly file contains a statement .eabi_attribute.

So the statements made by the submitter seem to be valid.

Alternative patch submitted by Stefan Sørensen, updated and tested today by me:
http://patchwork.ozlabs.org/patch/345703/

This patch compiles a temporary object instead of using libm or crt1.

Fixed with http://git.buildroot.net/buildroot/commit/?id=3787592063b0f30c69d074534a5a437bb458fbd7

Thanks for reporting!