Re: --host versus --target

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Trevor, All,

On Tuesday 15 November 2011 22:51:55 Trevor Woerner wrote:
> In the crosstool-NG documentation is "5 - Using the toolchain.txt". In
> there it recommends "using the target tuple to tell the build systems
> to use your toolchain" and then gives an example of specifying the
> '--target=tuple' option to 'configure'. Using crosstool-ng-1.13.1 I
> recently built an arm-cortex_a8-linux-gnueabi toolchain. Looking
> through the log file to see how, for example, strace was built for the
> target I can't help notice --target was not used, only --host. I also
> noticed that for all other tools --host is always specified.

Right, this is incorrect. This should be:
  ./configure --build=(build-tuple) --host=your-target-tuple

> I recently cross-compiled a system and never used --target, only
> --host. Are there any definitive answers on how --target and --host
> differ, or when they're needed (are they both needed, is only one
> required)? I'm surprised my using --host seemed to have worked when
> the documentation recommends --target.

The documentation is wrong, that's why! :-)

In the very beginnings, eons ago, autotools also got confused by this
whole build vs. host vs. target, and got it wrong. Now they fixed it,
but they want to keep backward compatibility, so the --target is still
recongised, although ./configure will complain if you do so.

So yes, --host is what you want. You should also pass --build, for
completeness...

> I also was wondering about the --sysroot=<DIR> CFLAGS option. As I
> successively compiled one package after another I kept installing them
> to a staging area then copying them into one combined tree (with the
> help of the populate script). Wouldn't it be necessary when
> cross-compiling for a given target to keep specifying --sysroot=<DIR>
> so the build machine's header files and libraries aren't accidentally
> referenced during the build?

There are three schools of thought here:

1) Those who want to install directly in the sysroot of the toolchain.
   Their argument is that the compiler will automagically find headers
   and libraries without extra flags.
   This means that the toolchain gets poluted, and can not be re-used.

2) Those who copy the toolchain's sysroot to a 'staging' area, where they
   install everything, and they pass --sysroot=staging to the compiler, so
   it automagically finds headers and libs.
   It's a viable option, but forces to always force CFLAGS to include
   --sysroot=staging, or requires the use of a wrapper to a few select
   tools (gcc, ld...) to pass this flag.
   That's what buildroot does using a wrapper, when using an external
   toolchain.

3) Those that use a staging area to install programs, but do not pre-fill
   that staging with the sysroot. They have to pass appropriate CPPFLAGS
   and LDFLAGS to tell the compiler where to find non-system headers and
   libs, or use a wrapper to a few select tools (gcc, ld...) to pass those
   flags.

I'm in favor of 3) but I have no strong opinion against 2) either; both
maitain the 'purity' of the toolchain. 1) is purely horrible, as the
toolchain gets polluted, and can not be re-used.

There's a 4th alternative, which is a bit more involved:

4) A mix of 2) and 3), using carefully crafted union mounts. The staging
   area is a union mount of:
     - the sysroot as a read-only branch,
     - the real staging area as a read-write branch
   This also requires passing --sysroot to point to the union mount, but
   has other advantages, such as allowing per-package staging, and a few
   more obscure pros. It also has its disadvantages, as it requires the
   possibility for non-root users to create union mounts; union mounts
   are not yet mainstream in the Linux kernel, so it requires patching;
   there is a FUSE-based unionfs implementation, but development is almost
   stalled, and there are a few gotchas...

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