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