On 8 March 2013 09:32, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Mar 08, 2013 at 09:04:19AM +0000, Marcus Shawcroft wrote: >> On 07/03/13 16:45, Jakub Jelinek wrote: >> >On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote: >> >>On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> >>>AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc. >> >>>directories similarly to x86-64 etc., but as aarch64 isn't a true >> >>>multilib target (having two different backends for 32-bit vs. 64-bit >> >>>code), >> >>>currently gcc -print-multi-os-directory prints . instead of ../lib64. >> >> >> >>I think glibc is broken also. So after this change, the build using >> >>the released 2.17 and this new gcc breaks. >> > >> >Then glibc will need patching too. Distros using multiarch aren't affected >> >by this, others IMHO will want it in */lib64 and for aarch64 IMHO it isn't >> >still too late for that change. >> >> Hi, Moving from /lib to /lib64 will affect binutils 2.23 (ld) and >> glibc 2.17. This seems to me to be a rather disruptive change this >> late in the day. > > Yes, it does affect them, on the binutils side it would be about > setting LIBPATH_SUFFIX=64 in ld/emulparams/aarch64linux.sh when appropriate > (grep LIBPATH_SUFFIX=64 ld/emulparams/*.sh to see what other targets do), > on the glibc side for other targets sysdeps/gnu/configure.in > is where libc_cv_slibdir and libc_cv_libdir are tweaked. > Note, this change doesn't affect multiarch, so Debian/Ubuntu is unaffected, > for others there can be an easy workaround for transitional period > (just add */lib64 -> */lib symlinks (or vice versa)). > The point of using */lib64 is that it is consistent with how most other > important 64-bit architectures are handled (x86_64, ppc64, s390x, sparc64, > mips64) and that even if you don't expect coexistence of 32-bit arm and > 64-bit aarch64 libraries on the same filesystem right now, using */lib64 > allows that in the future. Even if some distros use lib64 -> lib or vice > versa symlinks for some time if they choose so, if there is agreement to go > with lib64 path suffixes, it means packages that need to know this can be > changed, rather than adding horrible hacks to see what library suffixes > should be used.
My concern about the disruption associated with this change aside, I agree that the change needs to happen in order to avoid long term pain. I see no objections on this thread or the related thread over at glibc-ports, so go ahead and commit the patch. /Marcus
