Re: toolchain's sysroot via environment

[Arno Schuring <aelschuring at hotmail dot com>]

On 07/11/2010 08:44 AM, Enrico Weigelt wrote:
> * Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
>> Enrico, All,
>>
>> On Saturday 10 July 2010 17:44:57 Enrico Weigelt wrote:
>>> is there a way for passing the toolchain's sysroot prefix via
>>> environment, so one toolchain instance could be used for 
>>> multiple parallel builds ?
[...]
> Let me clarify by an example:
> 
> I've once built an toolchain one, lets say under /opt/x-tools/one.
> Now I'd like to start an build using /var/sysroot/1, and another
> one using /var/sysroot/2 - both at the same time.
> 

Regarding your first question: that's not possible - the sysroot paths
are compiled-in. If it were just the paths, if would not be much of a
problem - but the toolchain components (compiler, linker) are also
compiled differently based on the libraries available in the sysroot.

What I think you're trying to do, is to install into multiple different
prefixes because you want to build two separate systems? That's actually
doable, within limits. So I'm going to assume that I understood you
correctly - feel free to ignore the rest of the text if I didn't :)

First off, what the gcc toolchain calls a "sysroot" is not necessarily a
full "system". The term "libroot" would be more accurate, because it
only used to find the necessary files to cross-compile: headers and
libraries. And of these files, only the shared libraries are needed at
runtime (cue static linking and libnss debate).

When dealing with cross-compiling, you always have multiple copies of
the system files available. First, you have the location where the
cross-toolchain gets its information from. Let's stick with existing
convention and call it SYSROOT. Second, you have the actual system that
is (or will be) running the executables you are creating. Let's call it
the TARGET (no surprise, right?). You actually do not /need/ more than
that: you can just install all your files into sysroot, tar it up and
drop all your files on the target. But I've found it very convenient,
especially with slimmed-down embedded targets, to keep around a third
copy in which to do all the hard work (configuring, pruning). Let's use
glibc's INSTALL_ROOT for this intermediate tree.

What's important here is to realize that the SYSROOT tree has very
little in common with the TARGET tree: in an extremely minimal case, the
former contains only development files (headers, libraries) while the
latter contains only runtime files (binaries, data, configuration).
Using an intermediate step like an INSTALL_ROOT helps you to both keep
the toolchain clean (SYSROOT is part of the toolchain, after all), and
enables you to further prepare the filesystem you are going to put on
the TARGET. And, in your case, enables you to use multiple INSTALL_ROOTs.

Almost all source tarballs that support cross-compilation have a make
variable with which you can specify where to put the installed files
(autotools use DESTDIR -- glibc does not, of course). A "normal" build
system would just use DESTDIR=${SYSROOT} and be done with it. But if you
want your toolchain to be reusable, you need to specify a different
prefix, like /var/sysroot/1 in your example. But to keep terminology
correct, the toolchain would not be /using/ any of the files you install
there. It would only know about the files in SYSROOT.

That's why the toolchain part gets a little iffy: if you don't install
to SYSROOT, the compiler will not be able to find the header files of
newly installed packages. You must therefore make sure that all
development files make their way into the toolchain's SYSROOT. You can
do this by invoking "make install" a second time (with different
DESTDIR), or manually copying over everything you need. I suggest doing
it manually, at least the first time. But as long as you keep the
SYSROOT well-managed, there is no problem at all with compiling for ten
systems in parallel from the same toolchain. You might want to think
about precompiling some essential libraries (ncurses, openssl, libdb?)
and put them in SYSROOT before you start the parallel builds.

So where does this break down? If you need to target multiple systems
with different library versions. This is actually not a problem for the
libraries (they are versioned), but the header files: two header files
from different versions cannot co-exist in the same location.

And now to (finally) answer your question (well, the question I put in
your mouth): yes, you can compile for multiple systems from the same
toolchain in parallel, as long as you make sure that all development
files *also* end up in the sysroot path.


Final disclaimer: I haven't done any cross-compilation for the past two
years, someone please correct me where necessary.


Regards,
Arno

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