That's because it's linking against other libraries that are compiled for a different target. If you just compile a piece of code, you'll see that it compiles for the specified target:

It's not broken. glibc is built for for the software floating point ABI, and it's not part of a cross toolchain so there's no reason why it would be able to build for the hard float ABI.

This would not work anyway: the software floating point ARM port (14.2 and earlier) uses the software floating point ABI, which is incompatible with the hardware floating point ABI. This is not to do with the architecture (e.g. armv6, armv7) it's to do with the ABI.

Also, on -current (hard float ABI), since the OS is built for armv7 base line, building some a package for armv6 wouldn't make it work on the RPI0 because the RPI0 is only armv6. It's not like on 14.2 where the base line was armv5, so you could optimise your package for a more recent ARM CPU and have it still work (since the newer ARM CPUs are backwards compatible, but obviously the older models cannot be forwards compatible -- they don't have support for instructions that weren't invented when they were designed).

Thanks again for your time and clarifications, I'm starting to understand the limitations of the compiler (or toolchain as it is colloquially called now) on different arm architectures.
I'm sorry for calling the compiler on Slack ARM 14.2-softfloat broken, incomplete should have been used, as it is compiled, as you say, only for supporting soft float, that's why I got the error:
/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory
when trying to produce hard float armv6 code with the -mfloat-abi=hard compiler flag.
(still broken from my perspective )

Regarding the compiler from Slack 14.2-current, it does create native armv6 SoftFloat code that runs without any issues on the pi0. It's only when I use -mfloat-abi=hard the compiler is switching (without asking anyone) to armv7, thus the generated code = garbage = armv7 native code with armv6 specific hardware floating point code. And indeed it links the resulted binaries to the specific armhf libs that do not exist on Slack 14.2 softfloat:
ldd /tmp/build/usr/local/sbin/openvpn | grep armhf
/lib/ld-linux-armhf.so.3 (0x54b8b000)

I was under the impression that the arm implementation in the current compilers is mature enough and that you'd be able to crosscompile at least for the popular armv6/armv7/armv8/etc. architectures and that you could also have all the necessary SF/HF libs coexisting on your system. It looks like the toolchain from Linaro (Raspberry is using it) might be able to do that, although it doesn't come under GPL but EPL.
I guess I was also driven by my enthusiasm to use a Pi2B board (of which I have a few) and compile the necessary HardFloat bins and libs for the Pi0, that drove me to overlook all these interesting details. I might try the Linaro stuff and if I fail I'll switch to Gentoo for the Pi0.

I'm happy with all your help provided on this topic as it is pretty educative and gives a lot of clarifications. You might want to consider amending your original post and add that one is able to create HardFloat code only under Slackware 14.2 ARM - current and under Slackware ARM 14.2 - SoftFloat by rebuilding glibc with softfp he'd be able to compile and use HardFloat binaries but only for compatibility and not performance improvements. Actually, as per the Debian wiki, softfp will generate a lot of overhead and it's pointless to use.
Additionally, I can state that the performance improvement from SoftFloat to HardFloat is just plain MASSIVE! And not only for multimedia stuff but also for a lot of other usual stuff one might want to use on the ARM box. Obviously, for basic functionality, that's bash commands and basic Linux operations SoftFloat will suffice.

You're still confused about the ABI, it seems so I am going to quote from this URL:

https://raspberrypi.stackexchange.co...es-on-a-soft-f
According to the last sentence, you should be able to build statically on -current and run it on 14.2; but the sort of stuff you're building - there's no way you'd build it statically.
Therefore, even if I'd built the toolchain for -current to target armv6, you *still would not be able to run binaries from -current on 14.2* because the ABI's are incompatible.

This and having the toolchain output armv7a binaries despite trying to target armv6, but I explained that already.
This is one of the reasons why Raspbian exists - Debian targeted higher (as we do) than armv6.

You'd need a separate toolchain for armv6 -- the quotes above explain what's going on there.

Yep I will. I have never done it myself and didn't look at what the performance impact was.

Good to know - I've never measured it. I did notice that the machines running the h/f OS seemed more responsive, but never measured anything.

I was confused about the ABI and thanks again for your patience and effort in explaining it to me. You're the ARM expert! It starts to look like science to me BTW, with all this double-trouble = platform-specific & ABI-specific
Please add SoftFloat / HardFloat in your compilation explanations, it's confusing without them when related to ABI.

Basically, if I was to rebuild glibc for armv6, the only option I have is to use softfp for system compatibility (for the already in place binaries). If I'd rebuild glibc for armv6 with -mfloat-abi=hard, anyways I don't have a compiler (toolchain) under Slack able to do that, then due to the incompatible generated ABI I'll mess up the whole Slack 14.2 SoftFloat system. What a pity

On HardFloat performance, I remember installing Slack on my first Pi2B some years ago and by having some issues with the arm-mini-root images I only succeeded installing Slack ARM 14.2 SoftFloat for the first time (I was a noob - still am with respect to ARM). After a week or so I managed to get Slack 14.2 current HardFloat and it was like I got almost a doubling in performance on the services / programs I was using. I would like to add that I'm always recompiling the core components I'm using with -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard and I'm still amazed to this very day about how fast Slack HF on these little Pi2B "toys" is.

By looking up on this thread I saw louigi600's post about the kernel requirements for being able to "ingest" vfp code and pass it to the FPU. In this respect I checked the .config file from the Raspbian 4.4.50+ kernel and learned that it was built with generic VFP support:
#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y

Just for clarification, for those who don't know about, the folks at Raspberry are issuing two (there will be 3 with the Pi3B 64bit) Raspberry Pi specific kernel versions (and modules in /lib/modules) with their Raspbian image.
For example ending in "+" for armv6 and "v7+" for armv7:
4.4.50+
4.4.50-v7+
- corresponding to:
/boot/kernel.img
/boot/kernel7.img
In order to check if you have a kernel that supports HardFloat vfp operations you'd need to check the kernel .config file and to obtain it, run the following:
modprobe configs
config.gz is to be found in /proc
cp /proc/config.gz /your-folder
rmmod configs
cd /your-folder
gunzip config.gz
mv config .config
- voila! edit .config and check for whatever you're looking after.

I'm kinda perseverent by nature, it's a "defect" I got along with, and I've never gave up on Slack, at least not in the last ~18 years and I'm not ready to give up on it now due to this ARM mess.

In trying to understand the limitations of the compilers that come with both Slack ARM 14.2 SofFloat and Slack 14.2 ARM current - HardFloat and what I would need to prepare to produce armv6 HardFloat code, I've come across this very informative post:
https://stackoverflow.com/questions/...ith-a-single-g

and learned that both these compilers were built without multilib support.


Additionally, I've learned that with the Linaro compiler using -mfloat-abi=softfp is more restrictive as it looks in their documentation:
https://wiki.linaro.org/Linaro-arm-hardfloat
"
While soft/softfp are forwards compatible, ie. a 'soft' app can run on a softfp system -but not vice versa- a 'hardfloat' application can run on neither of those systems. This means that in order to use hardfloat the system has to be completely rebuilt for hardfloat, down to the last application.
"

Extra - HardFloat performance measurements from Linaro:
https://wiki.linaro.org/Linaro-arm-hardfloat
"
It has been shown [1] that a typical application built with hardfloat is 5-40% faster than the softfp version. In cases of heavy floating point use, the speed increase can go even further -eg. povray was proven to be >200% faster! [2] "

I guess, my approach to get a Slack armv6 HardFloat port will be to get a cross-compiler (gcc and not the one from Linaro) with multilibs first, then manually modify the SlackBuilds (adding armv6 HF flags) and building the miniroot and all the Slack packages I need from source. I'm really considering to do this on a powerful x86 system, suspecting that on a Pi2B it might take some days, and I'm not sure yet how to get such a cross-compiler environment producing arm code on a x86 box. Time to get busy!

@drmozes

You might want to consider removing or editing your statement from the first post (again), because it is still confusing:
- Slackware ARM 14.2 - SoftFloat (that's the only "rest as Soft Float") doesn't provide you with a compiler able to generate HardFloat code
- the person who wrote that How-To never states, or maybe corrected recently his blog entry, that by rebuilding some of the core components (with softfp support) you might be able to run HardFloat code on the SoftFloat system. He only states that he "optimized" the SoftFloat system. What softfp is actually doing, is just emulating HardFloat calls towards the kernel/FPU.
https://mindplusplus.wordpress.com/2...-raspberry-pi/
- as discussed before, softfp might create more overhead than simple soft and I'm still not sure why it was created in the first place:
https://wiki.debian.org/ArmHardFloatPort/VfpComparison
- the only way to run HardFloat code on a SoftFloat system is to use HardFloat binaries/programs that are statically linked with their depending libs and copy over those libs together with the binaries too.

Unfortunately I cannot edit the post - probably because it's years old.
I think that this discussion itself should suffice to explain the situation.
I might look to get the 'sticky' flag removed from the thread when a stable release of the hard float port is released, at which point it's 'just another release' (at least to me!) to which there is either no upgrade path, or a full reinstallation upon appropriate hardware.

@drmozes

I hope that too and also apologize for any of my posts that might have created some confusion. It was a learning experience on my side.

_______


There is a general question I have about the NEON SIMD instructions (introduced with Cortex-A7 and apparently becoming only optional with Cortex-A9) and considered to use this thread to address it. It's also related to HardFloat and VFP instructions.

Just a short intro and some details for the ones who are new with these SIMD instructions:
https://en.wikipedia.org/wiki/ARM_ar...IMD_.28NEON.29
https://developer.arm.com/technologies/neon
http://infocenter.arm.com/help/topic.../BABIIFHA.html
https://stackoverflow.com/questions/...n-how-to-start

There is a very good article with respect to ARM compilation and VFP options - in which it is described that one should use the -O3 gcc compiler optimization flag in order to start the auto-vectorizer and produce optimized VFP code (Section Adding floating-point and SIMD & Vectorizing floating-point operations):

https://community.arm.com/tools/b/bl...-command-lines

In another post it is stated that: floating-point operations will not be used by GCC's auto-vectorization pass unless `-funsafe-math-optimizations' is also specified. But I was able to generate (at least readelf is reporting: Tag_FP_arch: VFPv4 - Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC) NEON VFP code without using -funsafe-math-optimizations, but only -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard

https://stackoverflow.com/questions/...nd-compare-flo

My question:
Slack ARM -current HF is mainly compiled to use VFPv3-D16 VFP/FPU instructions and I'm not sure how NEON instructions are handled if an userland binary is compiled to use them (FFMPEG for instance has a NEON configuration switch and NEON specific source code). Are these NEON instructions passed directly to the kernel/FPU even if the system (some other dependent shared libs) is VFPv3-D16?