From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15125 invoked by alias); 27 Feb 2014 06:37:28 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 15112 invoked by uid 89); 27 Feb 2014 06:37:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f43.google.com Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 27 Feb 2014 06:37:26 +0000 Received: by mail-qg0-f43.google.com with SMTP id f51so4586070qge.2 for ; Wed, 26 Feb 2014 22:37:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gSNby2fwPCDY/b3qJJMTcgQHOkMs51HoeV/hUmCRs3E=; b=an1sSKBUqvLC4zBo46y9nBGXLsXdW7vpKFuwHJdtopva7iktDpad94SDsbt7IBwhlj MTm101T6YR9cxyy6ZQOjliJ+IEyVxkah4ZXAhy//33Fv0VJFnbzYYVR9qt8Dpz/01drX 0ytx6BHu4IH3gXau/Syxe0F+Bl8TmuusOlHkSP07CxMvewRjjdxbm4Ene286F1dP/PQ7 8rCjYt2ZW4hZupwfYdb1A2aLLO+4p0X9niH7EAnYBtOo2Zd4PA0EieTekSvkBVR5Tqzh 66Jn9kCFBy6kD6BKcBEDZu1e7KjumS6y4dHiTsJTiq9plJHy2dCJbKdMCO5OvCfGbjwk Rrkg== X-Gm-Message-State: ALoCoQmu5cdy0IGIbZn/D+5dAl6gFT5rumhfAVSPT8bh080yyTqKhmMrtPKo2btqT3Q1tXcICjOn X-Received: by 10.140.48.5 with SMTP id n5mr4812468qga.90.1393483043964; Wed, 26 Feb 2014 22:37:23 -0800 (PST) Received: from [192.168.123.135] (c-71-236-220-78.hsd1.wa.comcast.net. [71.236.220.78]) by mx.google.com with ESMTPSA id a5sm10667073qae.2.2014.02.26.22.37.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Feb 2014 22:37:23 -0800 (PST) Message-ID: <530EDD1F.2070602@codyps.com> Date: Thu, 27 Feb 2014 06:37:00 -0000 From: Cody P Schafer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ray Donnelly , Trevor Woerner CC: "crossgcc@sourceware.org" Subject: Re: multilib-list References: <530E2237.50603@linaro.org> <530E45F5.1040404@linaro.org> <530E7B42.5070409@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00077.txt.bz2 On 02/26/2014 04:37 PM, Ray Donnelly wrote: > Hey Trevor, Brian, all on list, > > On Wed, Feb 26, 2014 at 11:39 PM, Trevor Woerner > wrote: >> Hello Ray, Brian, and everyone else, >> >> On 02/26/14 15:05, Ray Donnelly wrote: >>> AFAIK, Bryan Hundven was going to exclude --with-multilib-list for arm >>> if gcc < 4.9, and exclude it altogether for all arches other than Intel, >>> arm and sh. >> >> It seems like a lot of initial (and on-going) work (multilib_add_archs) >> to keep track of which architectures and which versions have multilib >> support. I guess it would help users from accidentally creating invalid >> configurations, but on the other hand I can't help think it would be >> easier and more flexible to have the option always available (when >> multilib is selected) and include a strongly worded help message instead :-) >> > > multilib_add_archs isn't about hand-holding or sanitising the multilib variants > based on the arch (though there are other patches in the queue that do some > of that), instead, that bit is about determining the correct triplet to use > to configure {e}glibc given the C flags for that multilib variant and the > 'major' target triplet.The stub implementations are just NYI. > > To give a concrete example, on my multilib Arch system: > $ gcc --print-multi-lib > .; > 32;@m32 > .. so we know there's 2 variants, one with extra_flags of "" and one with > extra_flags of "-m32". We need to build {e}glibc twice then, once for > i686-unknown-linux-gnu and once for x86_64-unknown-linux-gnu. > This is done from glibc-eglibc.sh-common: > target=$(CT_DoArchMultilibTarget "${extra_flags}" ${CT_TARGET}) > > The other important thing this patch queue adds is to ask gcc where > these {e}glibcs should be installed using -print-multi-os-directory: > lib_dir=/usr/lib/$("${cross_cc}" -print-multi-os-directory ${extra_cc_args}) > (where extra_cc_args is extra_flags plus potentially some user requested > flags). This allows removing all of the symlinks from lib to lib32/lib64 that > were being made previously ( dont-make-lots-of-lib-symlinks-if-mutlilib ) > and also removing the ugly block "Fixing up multilib location" > ( use-multi-os-directory ) AFAIK newlib (which I expect Trevor is using for embedded arm targets) doesn't need any target mangling for multilib to work correctly. Which means for newlib targets multilib should work almost as-is. -- For unsubscribe information see http://sourceware.org/lists.html#faq