--host versus --target

[Yann E. MORIN]

Trevor, All,

On Wednesday 16 November 2011 21:18:07 Trevor Woerner wrote:
> playing with the cross-compiler's "-v" option I can see
> that it instead looks in all the proper locations for the
> cross-toolchain's #include files without considering the host system's
> default locations:
> 
> #include "..." search starts here:
> #include <...> search starts here:
> <ct-ng install path>/lib/gcc/i686-nptl-linux-gnu/4.5.2/include
> <ct-ng install path>/lib/gcc/i686-nptl-linux-gnu/4.5.2/include-fixed
> <ct-ng install path>/lib/gcc/i686-nptl-linux-gnu/4.5.2/../../../../i686-nptl-linux-gnu/include
> <ct-ng install path>/i686-nptl-linux-gnu/sysroot/usr/include
[--SNIP--]
> Just out of curiosity, why is the cross-compiler behaving this way
> (i.e. why isn't it searching for #includes in the system's
> /usr/include directory)? Is it because it is a cross-compiler, or
> because it is a sysroot'ed cross-compiler, or because it is performing
> a cross-compile?

All of that.

Because it is a cros-compiler, it is smart enough to not look for the
host (the host of the toolchain!) headers and libs, but in a specific
location specified at compile time (compile time of the toolchain!).

That location is what we call the sysroot. The sysroot was introduced
like 6-7 years ago IIRC. Before that, that location was not named
sysroot, although it did exist. But the gcc was not relocatable, and
there were other minor twists, but it's kind of blurry in my head.

Now, we have sysrooted toolchains. These are marvelous beasts, such that
if gcc is configured with a sysroot that is a sub-dir of its install
prefix, then the user can move the (full) toolchain to another directory,
and gcc will automagically find the new location of the sysroot! Magic! :-)

Non-sysrooted toolchains belong to the past, and they should not ever be
allowed to wander our Earth any more! :-)

> I noticed, while looking through the "-v" output that
> someone is including a --sysroot option implicitly.

That must be gcc calling ld.

The trick is, there can be more than one sysroot in a toolchain; gcc can
use some of its flags (eg. big/little endian, -march and so on...) to
select one sysroot or the other. This is called a multilib toolchain.
So, gcc has to tell ld what sysroot to use.

Although crosstool-NG is not yet capable of building multilib toolchains,
gcc has no way of knowing that there's only one sysroot, so it always
tells ld what sysroot to use, even if it's the default one.

(Well, there is a very promising patch recently submitted to support
multilib, but it needs some refreshing first).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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