From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26207 invoked by alias); 21 Dec 2007 09:17:07 -0000 Received: (qmail 26195 invoked by uid 22791); 21 Dec 2007 09:17:06 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0910.google.com (HELO rv-out-0910.google.com) (209.85.198.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Dec 2007 09:17:01 +0000 Received: by rv-out-0910.google.com with SMTP id g11so167775rvb.56 for ; Fri, 21 Dec 2007 01:16:58 -0800 (PST) Received: by 10.141.33.21 with SMTP id l21mr566819rvj.251.1198228618704; Fri, 21 Dec 2007 01:16:58 -0800 (PST) Received: by 10.141.195.16 with HTTP; Fri, 21 Dec 2007 01:16:58 -0800 (PST) Message-ID: Date: Fri, 21 Dec 2007 09:17:00 -0000 From: NightStrike To: "Kaz Kylheku" Subject: Re: More questions on sysroots Cc: gcc-help In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00372.txt.bz2 On 12/20/07, Kaz Kylheku wrote: > gcc-help-owner@gcc.gnu.org wrote: > > I thought I was doing the right thing for a while, but apparently > > there are still issues. If I want to build a complete toolchain as a > > canadian cross, tar it up, and give it to someone else, I have been > > doing the following for configuring binutils/gcc: > > > > ../gcc-svn/gcc/configure --prefix=/tmp/rt/root > > --with-sysroot=/tmp/rt/root --target=$TARGET > > Using the same value for sysroot and prefix is not such a hot idea. > > The sysroot corresponds to the root of the target filesystem that you > are building, or a least its toolchain materials, like usr/include and > usr/lib. > > This is not where you are installing the cross-compiler (which isn't > even compiled to run on that architecture). When you say "the root of the target filesystem", do you mean that it's the root of a directory structure containing target files that will be used while creating the toolchain, or that it's the root of a directory structure where the final toolchain, once built, will look for target files? I'm guessing the answer is "both"..... > > Will this combinations of options, after tarring up /tmp/rt/root, > > allow that tar to be distributed anywhere, untarred into any > > directory, and run as normal with nothing but a simple change to PATH? > > To build a relocatable toolchain (runs in any directory), the sysroot > has to be a subdirectory of the prefix. It doesn't have to correspond to > the prefix itself. It can be anywhere underneath. Exactly where, that's > up to you. > > You can just make up some subdirectory and stick it there. > > I use the scheme $prefix/$arch_string/root > > The reason for adding the architecture to the path is that the toolchain > can, in principle, be built for multiple targets, all installing to the > same prefix. (This is is supported). Yet each target needs a distinct > sysroot under there. > > So say you built for arm and mips. You'd end up with > $prefix/bin/mips-*-gcc and $prefix/bin/arm-*-gcc. Your sysroots in this > combo toolchain would be $prefix/arm-*/root and $prefix/mips-*/root. > Here * represents some additional components of the architecture tuple. > In my case this is ``linux'', since that's the target OS; the toolchain > is coupled with a Linux distro. So my C compiler would be: > > > /path/to/toolchain/bin/mips64-linux-gcc > > or alternately: > > /path/to/toolchain/mips64-linux/bin/gcc > > the sysroot is > > /path/to/toolchain/mips64-linux/root > > where we find > > /path/to/toolchain/mips64-linux/root/usr/include > /path/to/toolchain/mips64-linux/root/usr/lib32 > > etc. Note that the toolchain itself has lib and include directories: > > /path/to/toolchain/{include,lib} > > If we made that the sysroot, these would get mixed into the root. Is it absolutely *required* that the sysroot be a subdirectory of prefix to make the final toolchain relocatable, or is this where with-build-sysroot comes into play? I will definitely adapt my scripts as you suggest (I like that idea of the directory for the target arch), but I am still curious about how with-build-sysroot fits into this. The few sentences in the manual don't clear it up for me, nor does reading configure.ac. Also, is there an option that's just plain "--sysroot"? Does that have any meaning? Should it ever be used?