From: "Kaz Kylheku" <kaz@zeugmasystems.com>
To: "NightStrike" <nightstrike@gmail.com>
Cc: "gcc-help" <gcc-help@gcc.gnu.org>
Subject: Re: More questions on sysroots
Date: Fri, 21 Dec 2007 18:30:00 -0000 [thread overview]
Message-ID: <1106742C6EE944BC9D7488BFB2CC7E76@rocktron> (raw)
In-Reply-To: <b609cb3b0712210116h1ba437b0l44adab5c0d9927a5@mail.gmail.com>
"NightStrike" <nightstrike@gmail.com> wrote:
> 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".....
The asnwer is both. For instance, suppose you're making a cross-compiled
LInux system, and building a final user-space GCC which is integrated with
the GNU C library.
You would already have glibc built into the sysroot (as well, you'd of
course spin it into a package to install on the target system).
>> 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?
More precisely, from http://gcc.gnu.org/install/configure.html:
`` If the specified directory is a subdirectory of ${exec_prefix}, then it
will be found relative to the GCC binaries if the installation tree is
moved. ''
I think where --with-build-sysroot comes into play is that it allows these
target system materials (like glibc) to be pulled from somewhere other than
the sysroot location during the building of the cross compiler.
This provides some flexibility as to how to structure the cross compiler
build process, in certain situations.
I've built an entire Linux distro, including a cross toolchain that runs on
a build systems /and/ a native toolchain that runs on the target, without
ever needing to use --with-build-sysroot. It wouldn't be that helpful
because as soon as the compiler is built with the glibc materials, I want to
run it. And at that point, those materials must be in the sysroot location.
But I can imagine some situations where you don't want to run the compiler
that is built, but perhaps package it for someone else to run somewhere
else.
> Also, is there an option that's just plain "--sysroot"? Does that
> have any meaning? Should it ever be used?
That's not a build configuration option, but a run-time switch supported by
the gcc front end to override the sysroot location. There is probably a
situation in which this comes in handy, just not the normal case. I'm only
guessing, but it's probably useful during the staging of gcc. If you have a
partially built gcc which doesn't know anything about any sysroot,
then --sysroot can tell it where to look.
next prev parent reply other threads:[~2007-12-21 18:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 20:39 NightStrike
2007-12-20 21:23 ` Kaz Kylheku
2007-12-21 9:17 ` NightStrike
2007-12-21 18:30 ` Kaz Kylheku [this message]
2007-12-22 17:22 ` NightStrike
2007-12-22 17:46 ` Brian Dessent
2007-12-22 17:54 ` NightStrike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1106742C6EE944BC9D7488BFB2CC7E76@rocktron \
--to=kaz@zeugmasystems.com \
--cc=gcc-help@gcc.gnu.org \
--cc=nightstrike@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).