This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ARM: Use different linker path for hardfloat ABI


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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]