From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29530 invoked by alias); 25 Mar 2012 15:16:49 -0000 Received: (qmail 29521 invoked by uid 22791); 25 Mar 2012 15:16:47 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from oproxy9.bluehost.com (HELO oproxy9.bluehost.com) (69.89.24.6) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sun, 25 Mar 2012 15:16:32 +0000 Received: (qmail 12853 invoked by uid 0); 25 Mar 2012 15:16:31 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy9.bluehost.com with SMTP; 25 Mar 2012 15:16:31 -0000 Received: from 146-115-71-23.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.71.23] helo=[172.31.1.105]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SBpBF-0001Uq-8v; Sun, 25 Mar 2012 09:16:29 -0600 Subject: Re: GCC support libraries and sysroot From: Paul Smith Reply-To: paul@mad-scientist.net To: "Yann E. MORIN" Cc: crossgcc@sourceware.org, Michael Hope In-Reply-To: <201203251636.59673.yann.morin.1998@free.fr> References: <201203251636.59673.yann.morin.1998@free.fr> Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Mar 2012 15:16:00 -0000 Message-ID: <1332688586.4633.19.camel@homebase> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 146.115.71.23 authed with paul+mad-scientist.us} X-IsSubscribed: yes 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 X-SW-Source: 2012-03/txt/msg00055.txt.bz2 On Sun, 2012-03-25 at 16:36 +0200, Yann E. MORIN wrote: > > It causes GCC to install support > > libraries like libgcc_s.so into the sysroot instead of the default > > location which makes it tricky to replace the sysroot later. > > What I don't really understand is why gcc does not install those libs > in the sysroot. Why are those libs so special that they are "support > libraries" and they do not deserve being installed in the sysroot? > Yes, that's a real question I do not have the answer to. In my environments (although I'm not using crossgcc, I have my own makefile to build a "crosstools suite") I have the same situation as Michael. I have a single compiler toolsuite, and a number of different sysroots. I create these sysroots in different ways, depending on the target. Some of them I just went onto the target system and created a tar file containing the stuff I needed for the sysroot (I have a script that does this). Others I extract the upstream packages (RPM or DPKG) directly into a separate sysroot area. In any event, I would find it very annoying if GCC copied important internal files/libraries into the sysroot. I want my sysroots to be read-only and unmodified from the target, and the toolsuite libraries to be contained within the toolsuite environment. Cross-pollination between those would be extremely frustrating for me. If you did want to preserve this ability I would recommend doing it the other way: use the standard installation environment by default and offer a script that could be invoked to copy the toolsuite libraries into the sysroot. Not only would that give you a better idea of whether the extra step was necessary (people would know if they needed it, because they'd have to run the extra script), it would also allow sysroots to be updated "on the fly" instead of having them preinstalled. Personally I've not run across any packages which did not build properly unless the compiler libraries existed in the sysroot. They've all worked fine for me. However if there were packages that failed, in my opinion that would be an error in the upstream package and should be reported there and fixed. They're obviously doing something incorrect in their build environments. Cheers! -- For unsubscribe information see http://sourceware.org/lists.html#faq