Change the dynamic linker path for ARM hard float executables.
Matches the path discussed and agreed on last week[1]. Carlos will
follow up with the matching patch to GLIBC[2]. I'm happy to if he's
busy.
OK for trunk?
-- Michael
[1] http://sourceware.org/ml/libc-ports/2012-04/msg00060.html
[2] http://sourceware.org/ml/libc-ports/2012-04/msg00064.html
2012-04-23 Michael Hope <michael.hope(a)linaro.org>
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..3ddf812 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
/* Use ld-linux.so.3 so that it will be possible to run "classic"
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+ "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+ %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
FYI
-------- Original Message --------
Subject: Fedora 17 ARM Beta Release
Date: Thu, 24 May 2012 01:49:46 +0000
From: Paul Whalen <Paul.Whalen(a)senecacollege.ca>
Reply-To: users(a)lists.fedoraproject.org
To: announce(a)lists.fedoraproject.org <announce(a)lists.fedoraproject.org>
The Fedora ARM team is pleased to announce that the Fedora 17 Beta for
ARM is now available
for download from:
http://dl.fedoraproject.org/pub/fedora-secondary/releases/test/17-Beta/Imag…
Please visit the announcement page for additional information and links
to specific hardware images
as well as QEMU for those who lack ARM hardware.
http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_Beta
We invite you to take part in making Fedora 17 for ARM a solid release
by downloading, testing, and
providing your valuable feedback. Please join us on the IRC in
#fedora-arm on Freenode or send
feedback and comments to the ARM mailing list.
On behalf of the Fedora ARM team,
Paul
Hi,
Linaro connect Q2, approaching the schedule is getting ready. Here is
a selection of sessions most close to cross-distro people, but check
the schedule[1] for other sessions as well. I will link to remote
participation instructions once they are online.
Monday 28th May:
10:00 - 10:45 HKT (02:00-02:45 GMT) ARMHF status discussion
Meetup for folks interested in the hard-float ABI work, discussing
status to date and what's still remaining.
Tuesday 29th May:
08:30 - 09:00 HKT (00:30 - 01:00 GMT) ARM update Plenary
An overview of ARM’s current developments with emphasis on ecosystem
activity relative to Linaro and the open source community, both for
ARMv7 and plans for the emerging ARMv8 standard
Thursday 31st May:
09:00 - 09:55 HKT (01:00 - 01:55 GMT): Enterprise Bootloaders: UEFI,
ACPI, Device Tree Oh My!
Discuss bootloader requirements for enterprise grade Linux on ARM CPUs.
10:00 - 10:45 HKT (02:00 - 02:45 GMT) Cross-distro standardisation /
discussion session
ARM progress in various distros (including the new HF ABI) and
build/port issues - sharing ideas and problems that people may have
related to ARM porting
Riku
[1] http://connect.linaro.org/events/event/linaro-connect-q2-12/#schedule
Hi folks,
We really need to push on with getting the loader path for armhf
standardised. The path that was agreed months ago is
/lib/arm-linux-gnueabihf/ld-linux.so.3
but clearly not everybody is using that yet. Dann has just posted an
updated patch for gcc, and we want to get this reviewed / fixed up /
accepted ASAP. Then we may need to backport it to older gcc releases.
This is *important* so that we can help vendors release binaries that
work on any hard-float distribution. For people who have made binaries
that still use the old, broken location /lib/ld-linux.so.3, we can put
symlinks in place *for now* but in the longer term as many distros
switch to multi-arch the symlink is not an acceptable solution.
I'm working on a more complete spec document for armhf to help us with
this kind of thing, but it's not going as smoothly as I'd hoped and I
don't want to wait for that as a blocker on the linker path.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
