This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using sysrooted toolchain, or not?


Hi all,

sorry for chiming in. It's been a while since I have had a need to build
my own toolchains, but I thought I'd share my (limited) understanding of
sysrooted toolchains...

> On Friday 27 February 2009 08:37:24 michael wrote:
>> Thanks.  Although again it doesn't say a great deal about the non sysroot 
>> case, it does say "... you should not use [this] and ... it's a huge 
>> [pain in the arse]".
> 
> As I understand it, the toolchain would not be relocatable if you don't use
> sysroot. The gcc configuration doc says:
>   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.
> 
> At least, sysroot makes relocating the toolchain feasible, which indirectly
> means that non-sysrooted toolchains are not relocatable. But I may well have
> misunderstood...

Configuring binutils and gcc for sysroot support will cause the
toolchain components to prefix their search paths with the given
sysroot. That means that you will no longer need to provide separate
libs and headers to satisfy build dependencies. For example if you need
to build Bash for a non-sysrooted toolchain, you would need to install
ncurses and readline twice: once on the target/host tree (for runtime
.so linking), and once in $(toolchain)/lib/$(host_tuple)/{lib,include}
to satisfy Bash' build dependencies (or, conversely, use CFLAGS/LDFLAGS
variables).

As for the relocation case, I'm not sure if the gcc documentation is
talking about only libgcc, or that the entire sysroot can be relocated
as well. Never really had a need for it.

As I understand it, using sysroot has another advantage, in the way that
you configure packages that will run on the host: you can run configure
with the desired runtime paths (./configure --prefix=/usr
--sysconfdir=/etc), and install them via the DESTDIR parameter to make.
For the non-sysrooted case, you would need to ./configure
--prefix=$(tree)/usr, which will cause problems if those configure paths
end up being hardcoded in the executable.



Regards,
Arno

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]