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] |
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] |