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

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 2437 bytes --]

On Thursday 05 April 2012 12:25:09 Konstantinos Margaritis wrote:
> On Thu, 5 Apr 2012 11:55:14 -0400 Mike Frysinger 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.

i can see why bumping ver # is undesirable, but i don't think it's that big of 
a deal.  the ldso is a bit of a magic beast, so i don't think applying the 
same SONAME versioning rules is terribly important.  especially since ARM has 
already moved from ld-linux.so.2 for OABI to ld-linux.so.3 for EABI.  you 
could even argue that enshrining hardfloat is actually an ABI version bump, so 
ld-linux.so.4 is appropriate.  and really, once you bump the SONAME, injecting 
substrings like "hf" are no different.

> > 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,

i'm not familiar with ppc's embedded variants, so i can't speak to these 
examples

> 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.

i'm not sure why you think that.  if people actually want to do multilib with 
these, then there's nothing stopping people from doing that, once the ldso's 
are in a unique path.

> 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?

what Debian chooses to do with multiarch is up to Debian ... i don't think it 
should have any bearing here.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]