On Thursday 15 November 2012 07:07:17 Steve McIntyre wrote:
> On Thu, Nov 15, 2012 at 12:51:01AM -0500, Mike Frysinger wrote:
> >On Wednesday 14 November 2012 22:49:06 Jon Masters wrote:
> >> On 09/17/2012 06:24 AM, Wookey wrote:
> >> > The upstream patches have used the existing (poor man's
> >> > multiarch) paths:
> >> > /lib64
> >> > /usr/lib64
> >> > in order to make them fit in with existing upstream convention.
> >> 
> >> I originally wanted to use /lib, but we're going to switch to /lib64 for
> >> consistency with other 64-bit architectures, and so on. I am concerned
> >> that we agree on the linker, but not on other library paths. Will Debian
> >> and Ubuntu consider a package that includes /lib64 "compatibility"
> >> symlinks so that non-multiarch systems can share code with multi-arch
> >> ones? We don't need to break this :)
> >
> >in terms of binary compatibility, i don't think paths beyond the ldso
> >matter. when glibc is configured, you give it the lib paths to use, and
> >then at runtime you can add more stuff to /etc/ld.so.conf.  that means
> >distros can use whatever conventions they want as the ldso interp gates
> >it all, and compiled ELF applications only have that ldso path encoded in
> >them.
> 
> Mostly yes, but consider apps which include plugins too. :-/

with encoded rpaths, i'm not sure you'll get cross-distro convergence on that 
anytime soon.  as an example, kde/qt get parallel installed in different ways: 
some use /opt, some use /usr/<kde|qt><ver>, some use /usr/<os-multilib>/<kde|
qt><ver>.  maybe there are even others i haven't seen.

similarly, you have internal helper paths encoded and here we have /libexec/, 
/usr/libexec/, /usr/lib/<package-name|misc>/, /usr/<os-muliblib>/<package-
name|misc>/, and maybe other craziness.

aarch64's behavior (use lib64) is nothing new to the multilib scene (x86_64, 
mips n64, s390x, ppc64), and distros have handled it thus far.  i don't think 
we need to hold aarch64 hostage here to much larger/ugly issues that are not 
as common.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro

Reply via email to