Re: More questions on sysroots

[NightStrike <nightstrike@gmail.com>]

On 12/20/07, Kaz Kylheku <kaz@zeugmasystems.com> 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?