--host versus --target
Yann E. MORIN
Tue Nov 15 22:49:00 GMT 2011
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
> 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
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
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...
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
More information about the crossgcc