Re: armelfp: new architecture name for an armel variant
In theory that should never happen! Mixing soft and hard abi objects should fail to link - either binutils is busted or ld.so is not checking.
Soft and softfp are capable of being stuffed together because the data is always passed via integer registers or stack the same way but hardfp binaries... No way. Launching a hardfp binary on soft or softfp libc should fail nice and hard :)
That said there is no hard requirement in the abi docs for it. Gcc will fail to link because it needs to collect together objects with the same abi - but I can't say the same about ld.so checking and to be honest I would not know where to look to check.
On Jul 8, 2010, at 8:06 PM, Martin Guy <email@example.com> wrote:
> On 7/9/10, Martin Guy <firstname.lastname@example.org> wrote:
>> Any mistake by users trying to mix the regular armel packages and
>> the hardfloat ABI ones would just fail immediately.
> Erm my mistake. *Should* fail immediately but don't.
> I just ran some tests on Maverick hardfloat in a Debian armel
> environment, and gcc-4.2 and 4.3 happily link -mfloat-abi=hard and
> -mfloat-abi=soft objects together to give executables that return
> complete rubbish.
> So it looks like a new arch name is necessary to stop people mixing
> the package types. :(