From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17396 invoked by alias); 14 Mar 2013 18:07:30 -0000 Received: (qmail 17381 invoked by uid 22791); 14 Mar 2013 18:07:28 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Mar 2013 18:07:20 +0000 Received: from sccc-66-78-236-243.smartcity.com ([66.78.236.243] helo=[10.35.3.16]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1UGCYd-0001Yd-Mn; Thu, 14 Mar 2013 18:07:15 +0000 Message-ID: <514211D0.8020407@ubuntu.com> Date: Thu, 14 Mar 2013 18:07:00 -0000 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Marcus Shawcroft CC: Jakub Jelinek , Marcus Shawcroft , Andrew Pinski , Paolo Bonzini , Alexandre Oliva , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] Fix -print-multi-os-directory for aarch64 References: <20130307111536.GA12913@tucnak.redhat.com> <20130307164501.GI12913@tucnak.redhat.com> <5139A993.4010906@arm.com> <20130308093239.GO12913@tucnak.redhat.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------010000070508000508060906" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg00517.txt.bz2 This is a multi-part message in MIME format. --------------010000070508000508060906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 3156 Am 14.03.2013 16:37, schrieb Marcus Shawcroft: > On 8 March 2013 09:32, Jakub Jelinek 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 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 --------------010000070508000508060906 Content-Type: text/x-diff; name="lib64.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lib64.diff" Content-length: 606 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) --------------010000070508000508060906--