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 Wed, Oct 05, 2011, dann frazier wrote:
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?
- -dynamic-linker " LINUX_DYNAMIC_LINKER " \
- %{msoft-float:-dynamic-linker " GLIBC_DYNAMIC_LINKEREL "} \
- %{mfloat-abi=soft*:-dynamic-linker " GLIBC_DYNAMIC_LINKEREL "} \
- %{mhard-float:-dynamic-linker " GLIBC_DYNAMIC_LINKERHF "} \
- %{mfloat-abi=hard:-dynamic-linker " GLIBC_DYNAMIC_LINKERHF "} \
There's an unfortunate issue with spec files which will prevent the biarch case from supporting -mhard-float/-msoft-float along -mfloat-abi in the near term: http://lists.linaro.org/pipermail/linaro-toolchain/2011-March/000964.html
Otherwise, looks good to me; thanks for the patches
On 05/10/11 17:54, Loïc Minier wrote:
On Wed, Oct 05, 2011, dann frazier wrote:
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?
- -dynamic-linker " LINUX_DYNAMIC_LINKER " \
- %{msoft-float:-dynamic-linker " GLIBC_DYNAMIC_LINKEREL "} \
- %{mfloat-abi=soft*:-dynamic-linker " GLIBC_DYNAMIC_LINKEREL "} \
- %{mhard-float:-dynamic-linker " GLIBC_DYNAMIC_LINKERHF "} \
- %{mfloat-abi=hard:-dynamic-linker " GLIBC_DYNAMIC_LINKERHF "} \
There's an unfortunate issue with spec files which will prevent the biarch case from supporting -mhard-float/-msoft-float along -mfloat-abi in the near term: http://lists.linaro.org/pipermail/linaro-toolchain/2011-March/000964.html
Otherwise, looks good to me; thanks for the patches
Perhaps something like this?
%:arm_choose_dynamic_linker(%{msoft-float&mhard-float&mfloat-abi=*})
And then implement arm_choose_dynamic_linker in driver-arm.c (which doesn't yet exist for arm, but will once my native tuning patch is approved).
Andrew
On Wed, Oct 05, 2011 at 09:06:09AM -0600, dann frazier wrote:
+#define GLIBC_DYNAMIC_LINKEREL "/lib/arm-linux-gnueabi/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKERHF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
As mentioned on IRC, I'm happy with this second patch, if you 's,arm-linux-gnueabi/,,' on the EL path. Also, "EL" seems pretty Debian specific (coming from "armel", I assume), you might want to change that to LINKERSF if you want it to make more sense upstream.
While I'd love to force a multi-arch path on soft-float users, that requires a migration path, and realization that it wouldn't be even remotely backward-compatible, so probably best to leave it alone and just move the hard-float path as discussed and agreed on. :P
... Adam
-
Adam Conrad -
Andrew Stubbs -
Andrew Stubbs -
dann frazier -
Loïc Minier