it seems the best choose is gcc-4.6.x and (e)glibc-2.13.x .
Is there some good technical reasons to choose eglibc? I say something like Neon optimized code or some "option group" that could build lighter 'n faster binaries.
E.g. LIBM_BIG if there is no reason to rely on precise floating-point math... anyway what's about CORTEX-A8 (fp double precision) and NEON abilities??
This is indeed the right choice right now -or at least it's the choice made for Debian armhf. We used for a almost a year gcc-4.4 (with Linaro branch), then switched for a very short period to gcc-4.5, but now that Debian (and Ubuntu) is switching altogether to gcc-4.6, we will follow that switch as well. This means that we won't be using the Linaro branch, but rather the FSF 4.6 tree by default -which includes the hardfloat changes. Regarding eglibc, yes, it's definitely worth switching to it, ignore plain glibc, at least you'll have much better chance to push your patches in, and not have to worry about dealing with Drepper at all. Right now it fails on armhf here, but it's something we'll fix asap.
And again... as the best option seems to be -mfloat-abi=hard and -mabi=aapcs but what happens if in the next future there will be released an "arm generic" closed binary (i can think to skype or adobe flash player)? Shell we be unable to use them?
Once we'll have a respectable userbase for ARM hardfloat distros, skype, flash and other closed-source binaries, will definitely follow suit. You can be certain this will happen, as Ubuntu have announced a migration is taking place as we speak, Meego is already hardloat, Fedora also, Gentoo -and of course let's not forget Debian :)
And again... is arm-unknown-linux-gnueabi the universal ABI name for the armhf build too ?
The "official" triplet for hardfloat -ie the one that has been decided by both dpkg and upstream gcc maintainers is arm-linux-gnueabihf.
And again... -mfpu=neon -funsafe-math-optimizations is it enough stable to build a distro?
I don't think so, and I wouldn't advise it. For one thing, both NEON fpu math and -funsafe-math-optimizations, are known to break IEEE754 floating point accuracy. It's possible that some packages will break if the accuracy is not the one expected, I'm pretty sure some testsuites will break. OTOH, on some selected libraries it would make sense.
Debian armhf uses -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb, by default.
bzip2,xz,openssl,fftw and others:
is there some i.MX5 optimizations?
For iMX515, that can either mean a) NEON optimizations, or b) security optimizations using the SAHARA unit. For both meanings though the answer is no :(
Though we are planing to do a /dev/crypto implementation for the SAHARA unit, which will at least be used by openssl. It won't be much faster, but it will at least offload the cpu from crypto stuff.
OpenJDk/IcedTea and OOo/LibreOffice:
are they capable to successfully finish a "native" build?
OpenJDK needs to be bootstrapped first, for that to happen, it needs a working java compiler to exist, in our case it needs gcj/gij. This one builds, but it fails to run any java code (it's a known issue with libffi, libffi has been fixed to cater for hardfloat now, but there was a change in the API and we need to fix gcj/gij as well to work with the new API).
what's about libdrm,mesa3d,xf86-video-imx ?
all those should work/build for hardfloat, *but* there would be no 3D support yet, at least not until one particular static library available from Freescale/AMD is built and released using a hardfloat ABI.