From patchwork Fri Jan 10 11:06:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Klose X-Patchwork-Id: 309255 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id DB4A12C00A6 for ; Fri, 10 Jan 2014 22:07:06 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=od1SddlXWZTndJAEs9/5uhVxajEZ4CY6FiTko/wdAELNzJsSuVV/x 39ntnScSry/EtOFodkhS21blKgsiQ8CAh4y37MPu9gMDohuGCQqawhGEH4/un177 szGnoD6zn8TFUM59lLVOa1MWwJcUUuSYESY0eT9mxd9jCbtOtFsQPk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=BLcgky7DFm2/3ga7IvuR3ucCwgs=; b=PZ4RFEBqxuN6cOrh52Ih0UGaU4N7 eYjWQVHBQ+t8qbF1mPUvulZ30ZHxxYSr4qiB4kdXJnmFbtxPd0+am42QyUmDfVMe RVarF/lfQjP3l2SZRIc2klWec7mMhjPLBGCbBOP+Gt4BTdc1Tc1q4UIexdm31RgI oYlQ2m0iH9jkYpY= Received: (qmail 1224 invoked by alias); 10 Jan 2014 11:06:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 1207 invoked by uid 89); 10 Jan 2014 11:06:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: einhorn.in-berlin.de Received: from einhorn.in-berlin.de (HELO einhorn.in-berlin.de) (192.109.42.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 10 Jan 2014 11:06:56 +0000 X-Envelope-From: doko@ubuntu.com Received: from [192.168.42.220] (dslb-088-073-066-077.pools.arcor-ip.net [88.73.66.77]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id s0AB6dSV022626 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 10 Jan 2014 12:06:41 +0100 Message-ID: <52CFD42A.7030305@ubuntu.com> Date: Fri, 10 Jan 2014 12:06:18 +0100 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Zhenqiang Chen CC: "gcc-patches@gcc.gnu.org" , Yufeng Zhang , Marcus Shawcroft Subject: Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build References: <52CFBC2F.9040004@ubuntu.com> In-Reply-To: Am 10.01.2014 10:49, schrieb Zhenqiang Chen: > On 10 January 2014 17:23, Matthias Klose wrote: >> Am 10.01.2014 09:23, schrieb Zhenqiang Chen: >>> Hi, >>> >>> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been >>> combined in MULTILIB_OSDIRNAMES. >>> >>> But MULTIARCH_DIRNAME was re-added @r201164. With this change, the >>> final multiarch_dir is combined as >>> "aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to >>> multiarch build fail if the sysroot is in correct multiarch layout. >>> >>> Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we >>> remove it as the patch? >> >> see the thread "[patch] set MULTIARCH_DIRNAME for multilib architectures" from >> June 2013. I think it is necessary to have the default defined. Yesterday's >> build looks ok for me, looking at default and include paths, so maybe I don't >> yet understand the issue. > > In our build, we configure eglbc with > rtlddir=/lib > libdir=/usr/lib/aarch64-linux-gnu > slibdir=/lib/aarch64-linux-gnu > > And we configure gcc with "--disable-multilib --enable-multiarch", > But when building gcc libraries, configure FAIL since it can not find > the C libraries. And I try > ./xgcc --print-multiarch > the output is "aarch64-linux-gnu:aarch64-linux-gnu" > > Any comments? > > Thanks! > -Zhenqiang > > > >> I think aarch64 is the only architecture which introduces MULTILIB_* macros >> without actually building any multilib, just to set the default library name to >> lib64. So maybe this has some side effects. sorry, I have a local patch applied after the lib64 change, which I forgot to forward. * Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if MULTILIB_OSDIRNAMES is not defined. applied/tested since July 2013 on the Debian/Ubuntu distro builds. It doesn't affect the non-multiarch case. Ok for the trunk? Matthias --- a/src/gcc/Makefile.in +++ b/src/gcc/Makefile.in @@ -1837,7 +1837,7 @@ "$(MULTILIB_EXCLUSIONS)" \ "$(MULTILIB_OSDIRNAMES)" \ "$(MULTILIB_REQUIRED)" \ - "$(MULTIARCH_DIRNAME)" \ + "$(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME))" \ "$(MULTILIB_REUSE)" \ "@enable_multilib@" \ > tmp-mlib.h; \