From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1656 invoked by alias); 8 Mar 2013 09:33:30 -0000 Received: (qmail 1647 invoked by uid 22791); 8 Mar 2013 09:33:28 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Mar 2013 09:32:48 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r289WibW010222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Mar 2013 04:32:44 -0500 Received: from zalov.cz (vpn1-6-72.ams2.redhat.com [10.36.6.72]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r289WgW2026947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Mar 2013 04:32:43 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r289WfOH026553; Fri, 8 Mar 2013 10:32:41 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r289WeGc026552; Fri, 8 Mar 2013 10:32:40 +0100 Date: Fri, 08 Mar 2013 09:33:00 -0000 From: Jakub Jelinek To: Marcus Shawcroft Cc: Andrew Pinski , Paolo Bonzini , Alexandre Oliva , Matthias Klose , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] Fix -print-multi-os-directory for aarch64 Message-ID: <20130308093239.GO12913@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20130307111536.GA12913@tucnak.redhat.com> <20130307164501.GI12913@tucnak.redhat.com> <5139A993.4010906@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5139A993.4010906@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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/msg00334.txt.bz2 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. Because of disagreements (even when the psABI talked about lib64), we ended up with hacks like: MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-linux-gnu) MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:i386-linux-gnu) MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-linux-gnux32) on x86_64-linux, so if the decision on */lib vs. */lib64 on aarch64 is left to everybody and there is no agreement, we'll need similar hacks for config/aarch64/t-linux, something like MULTIARCH_DIRNAME = $(if $(shell test -d $(SYSTEM_HEADER_DIR)/../../usr/lib64 -a ! -L $(SYSTEM_HEADER_DIR)/../../usr/lib64 && echo lib64),,$(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu)) MULTILIB_OSDIRNAMES = $(if $(shell test -d $(SYSTEM_HEADER_DIR)/../../usr/lib64 -a ! -L $(SYSTEM_HEADER_DIR)/../../usr/lib64 && echo lib64),.=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)) (i.e. if /usr/lib64 is a directory and not a symlink, use ../lib64 multi-os-directory, otherwise . . The issue is that all the effected packages would need to contain similar hacks (gcc, binutils, glibc, libtool, ...). Jakub