Am 14.03.2013 16:37, schrieb Marcus Shawcroft: > 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.
sorry, didn't comment about this patch because it didn't seem to affect multiarch. However this patch assumes that every system does have at least a */lib64 symlink, if it doesn't have a */lib64 directory. I think that is a wrong assumption. Things like $ gcc --print-file-name libc.so /usr/lib/gcc/aarch64-linux-gnu/4.8.0/../../../lib64/libc.so would point to a non-existing path. Attaching a patch which uses a check to only set this to ../lib64 if it does exist, as done for other multilib configurations. Matthias
Index: gcc/config/aarch64/t-aarch64-linux =================================================================== --- gcc/config/aarch64/t-aarch64-linux (revision 196661) +++ gcc/config/aarch64/t-aarch64-linux (working copy) @@ -22,4 +22,4 @@ LIB1ASMFUNCS = _aarch64_sync_cache_range AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be) -MULTILIB_OSDIRNAMES = .=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu) +MULTILIB_OSDIRNAMES = .=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib64),../lib64,../lib)$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)