This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
- From: Konstantinos Margaritis <konstantinos dot margaritis at linaro dot org>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: cross-distro at lists dot linaro dot org, Dennis Gilmore <dennis at gilmore dot net dot au>, libc-ports at sourceware dot org, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <rearnsha at arm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 5 Apr 2012 19:25:09 +0300
- Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI
- References: <20120329193401.GA14860@dannf.org> <201204051108.58683.vapier@gentoo.org> <20120405182415.8aaa8b25181e0b46b5f501ef@linaro.org> <201204051155.16655.vapier@gentoo.org>
On Thu, 5 Apr 2012 11:55:14 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or
> /libhf/ld-linux.so.[34]. /lib/<triplet>/<ldso> is really the only one i don't
> think doesn't belong.
and I'm just saying that I dislike /libhf, I also think that just raising the version is a wrong solution.
> don't really know what you're talking about here. other distros have no
> problem with handling multilib.
multilib for softfloat/hardfloat on arm? I don't think so, even for other arches -it was already demonstrated that you cannot e.g. have powerpc e500v2 and e600 installed concurrently, and anyway that's not the topic of the discussion here. Apart from multiarch there is no other solution to do that *for* arm, at least at the moment, because the two ABIs use exactly the same paths on a non-multiarch system. And I get back to the proposed solution /libhf -which is the multilib path you're referring to- and I'm saying that the topic here is for the linker path alone. In the hypothetical scenario that everyone agreed on /libhf for the linker path, but not for libraries -which would stay in /lib- , then we'd have a /libhf top directory with just one file, the linker. Or a symlink from /lib to /libhf or /lib/<triplet> to /libhf in Debian's case, but that defeats the purposes of having a new /libhf directory, doesn't it?
I hope I was clearer now.
--
Konstantinos Margaritis <konstantinos.margaritis@linaro.org>