![](https://seccdn.libravatar.org/avatar/180af46c88299adabb86d6b76e9f13a6.jpg?s=120&d=mm&r=g)
On Tue, Nov 08, 2011 at 04:12:10PM +0100, Alexander Graf wrote:
On 11/08/2011 03:18 PM, Steve McIntyre wrote:
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it. Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
I'm not sure what exactly you're referring to. IIRC RPM (at least last time we checked) ignored the gnueabi flag for the comparison. I haven't really dug into the problem myself too much though.
There's been a lot of discussion already between folks at RedHat/Fedora, Ubuntu, Debian, Meego etc. about how to make sure that we can get binaries working across ARM platforms. In the past, there has not been much of a push for this. But in future we're expecting that this is going to be more and more important, as we get more standardised platforms (e.g. for ARM servers) where people will expect to be able to distribute single binaries for all platforms. Think Java, or the binary OpenGL/GLES graphics drivers that the chip vendors provide. We're expecting that the standard 32-bit ARM ABI in the future is going to be hard-float, and using a common triplet to describe it is important. "arm-linux-gnueabihf" is what was agreed by lots of people back at Plumber's in September, and we're working on pushing that into upstream gcc too. There's more than just RPM to consider... :-)
Adrian and Dirk, do you remember what exactly the problems were we were facing?
Yup, please share! Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org