At the ARM mini-summit there was a decision to change the linker path
encoded in binaries for the armhf port from:
/lib/ld-linux.so.3
to:
/lib/arm-linux-gnueabihf/ld-linux.so.3
Well, that's what I was told at least, room was too full when I got
there :)
I made an attempt at changing this simply by changing the static path,
but I got some feedback that pointed out this has problems on
(bi-|multi-) arch systems. So, I made a second pass by modifying the
linker spec to make this a runtime decision.
At this point I'd like to submit both patches as an RFC. I suspect the
static patch might be fine (and safest) for distributions like Debian
that don't yet enable bi-arch on armhf, but not for distros like
Ubuntu which do. The dynamic version should work in the bi-arch case,
but it also will change the default linker path for soft-float
binaries and I suspect we *don't* want to do that. Perhaps we need to
#ifdef that out somehow if we're building for a soft-float default
target?
Also, first time I've touched gcc spec files, so if anyone sees
anything that might be wrong, speakup - you're probably right :)
On 28.09.2011, at 12:50, Steve McIntyre wrote:
> On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
>> On 27.09.2011, at 18:19, Steve McIntyre wrote:
>>>
>>> Out of curiosity, what are you using as a triplet for your hard-float
>>> port? The discussion at LPC focussed on this to some extent:
>>>
>>> http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
>>
>>
>> Ah, nice. I didn't find that mail before. I only found one where the
>> discussion on the target names "armhf" and "armv7hl" was raised, so
>> we named the target "armv7hl" to be compatible with Fedora and Meego.
>
> Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l).
Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages.
We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here?
Alex
Please coordinate with Jon Masters at RedHat/Fedora and Adam Conrad at
Ubuntu/Debian on this. (Cc'ing the cross-distro list, through which the
recent ARM summit at Linux Plumbers was organized.)
Cheers,
- Michael
On Sep 16, 2011 8:41 AM, "David Gilbert" <david.gilbert(a)linaro.org> wrote:
> OK, so we seem to have agreement here that what we want is autodetect
> for eglibc and
> forget about the triplet; well technically that probably makes my life
> easier, and I don't
> think it's too hard a sell.
>
> Dave
>
> _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
