--host versus --target

--host versus --target

[Trevor Woerner]

Hi,

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.

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.

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?

Best regards,
    Trevor

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

Re: --host versus --target

[Michael Hope]

On Wed, Nov 16, 2011 at 10:51 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> Hi,
>
> 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.
>
> 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.

Hi Trevor.  The short answer is for most programs you set host to the
machine the program will run on, such as
--host=arm-cortex_a8-linux-gnueabi.  For unusual programs like GCC and
GDB where you run the program on x86 but target something else, you
use --host=x86... --target=arm-cortex_a8-linux-gnueabi.

So build==the machine used to build the program, host==the machine the
program runs on, and target==the machine the program works against.

-- Michael

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

Re: --host versus --target

[Yann E. MORIN]

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

Re: --host versus --target

[Trevor Woerner]

Thank you, Michael and Yann, for the quick and detailed responses!

I wasn't aware there existed different strategies for putting together
a cross-root-filesystem, I'm quite happy you took the time to list
them. Ironically, looking through the list (and I realize you're not
going to agree) I think option #1 is the best. Having recently put in
the time to put together such an image, I can attest it was quite a
pain getting the various packages to compile correctly. If I was
_really_ lucky, what I was trying to compile would have autotools
support, but even then CFLAGS would often not be handled correctly. So
specifying a value for CFLAGS on the cmdline would often clobber flags
the package needed to compile correctly. Then, I would often
additionally need to specify "-L" options so the linker so it could
find the libraries against which I wanted to link (why the link step
wouldn't work even though I was providing --sysroot is a bit of a
mystery still). If the package used C++ I would then have to
determine/guess if I needed to use CPPFLAGS, CXXFLAGS, or CCFLAGS.

I can appreciate you have your reasons for not liking option 1, but
from my point of view: for what other purpose does the cross-compiler
exist other than to create a cross-filesystem? It's not like I'm going
to then use the cross-compiler to cross-compile random bits and pieces
which aren't going to be put on the image anyway, so preserving its
integrity is irrelevant to me. Besides, for all the effort and
trail-and-error it would save me, I'd rather just rebuild the cross
toolchain and have multiple copies of it installed on my development
machine if I needed a pristine one or was putting together multiple
images. I'm guessing there are probably other reasons?

I'm assuming, however, to use option 1 I would need to specify the
toolchain's sysroot directory as the --prefix? Won't that mess up the
dynamic loader on the target (although if all libraries are installed
to $SYSROOT/lib and $SYSROOT/usr/lib I'm guessing it'll just work)?

Best regards,
    Trevor

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

Re: --host versus --target

[Yann E. MORIN]

Trevor, All,

On Wednesday 16 November 2011 17:16:08 Trevor Woerner wrote:
> I can appreciate you have your reasons for not liking option 1, but
> from my point of view: for what other purpose does the cross-compiler
> exist other than to create a cross-filesystem? It's not like I'm going
> to then use the cross-compiler to cross-compile random bits and pieces
> which aren't going to be put on the image anyway, so preserving its
> integrity is irrelevant to me. Besides, for all the effort and
> trail-and-error it would save me, I'd rather just rebuild the cross
> toolchain and have multiple copies of it installed on my development
> machine if I needed a pristine one or was putting together multiple
> images. I'm guessing there are probably other reasons?

Yes, a toolchain that is shared betwen many developpers. For example,
consider this situation:
 - 10+ hardware targets, of different architectures (ARM, x86, MIPS...)
 - 50+ projects
 - team of 150+ developpers
 - team dedicated to the tooling (toolchains, build system...)

In that situation, you want to ensure all developpers have the same tools
for a given tuple {project,target}, but you can't replicate the toolchains
for every developpers, or upgrades would be a ultimate burden. Also, you
do not want to allow each developper to fiddle with the toolchain, or it
would no longer be the same toolchain other developpers are using.

So, you do not want the toolchain sysroot to be polluted with what every
developer wants to install on his rootfs.

Yes, this is a common situation in an industrial context...

> I'm assuming, however, to use option 1 I would need to specify the
> toolchain's sysroot directory as the --prefix?

No, you want to set prefix to the _runtime_ prefix, probably / or /usr or
/usr/local. And you want to use: make DESTDIR=/path/to/staging install.

> Won't that mess up the
> dynamic loader on the target (although if all libraries are installed
> to $SYSROOT/lib and $SYSROOT/usr/lib I'm guessing it'll just work)?

The problem will not be, in the common case, with the dynamic linker.
ELF headers only list the name of the libraries to load, not their paths,
so the dynamic linker will succesfuly find libraries at runtime.

The problem will arise when programs will try to load their data, because
they were configured to expect everything in (say) /home/foo/blabla/sysroot
but this path does not exist at runtime, so they would fail to load:
 - their ressources (icons, images...)
 - their dlopen-ed libraries
 - the libraries in RPATH (RPATH is a beast to deal with, though with a bit
   of fiddling, it can be made to behave)

So what you want to do, is:
  ./configure --build=build-tuple --host=host-tuple    \
              --prefix=/usr --enable-foo-bar...
  make
  make DESTDIR=/path/to/staging install

and repeat for all your packages. Then if you used the sysroot as staging,
you'd have to push that to the target rootfs (eg. filesystem image, copy
to NFSroot...), but you would endup with lots of cruft: headers, static
libs, many other things that makes the sysroot usefull at build time, but
are mostly useless at runtime. Then you'd have to clean it up. Basically,
about 75% (size wise) of a uClibc sysroot is useless at runtime (32MiB, vs.
only 8MiB for all .so files). It's even worse with glibc.

With the third alternative, you only have to copy the _required_ files
from the sysroot to the staging, by scanning all ELF files from your
staging, on fetching the NEEDED files from the sysroot. Crostool-NG
installs a program that does just that: tuple-populate

Of course, it means you indeed have to pass appropriate CPPFLAGS to point
to where your non-sysroot headers are, and proper LDFLAGS to where non-
sysroot libraries are, eg.:
    CPPFLAGS="-I/path/to/staging/usr/include"                       \
    LDFLAGS="-L/path/to/staging/lib -L/path/to/staging/usr/lib"     \
    ./configure blabla-as-above...

Solution two would mean:
    cp -a $(tuple-gcc --your-cflags-except-sysroot -print-sysroot)  \
       /path/to/staging
    ./configure --blabla-as-above                                  \
                CC="tuple-gcc --syroot=/path/to/staging"           \
                CXX="tuple-g++ --sysroot=/path/to/staging"         \
                LD="tuple-ld --sysroot=/path/to/staging"           \
                AND_SO_ON=tuple-andsoon --sysroot=/path/to/staging"

Or you would need to provide a wrapper to gcc, and still tell configure
where to find it... Sigh, that's not easy...

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

Re: --host versus --target

[Trevor Woerner]

Yann,

On Wed, Nov 16, 2011 at 1:12 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
>> I'm assuming, however, to use option 1 I would need to specify the
>> toolchain's sysroot directory as the --prefix?
>
> No, you want to set prefix to the _runtime_ prefix, probably / or /usr or
> /usr/local. And you want to use: make DESTDIR=/path/to/staging install.

Thank you, now I understand.

I had been under the mistaken assumption that the cross-compiler would
perform its #include search with the host system's /usr/include
(etc...) by default (just like my system's native compiler). If that
were the case I would have to somehow tell the compiler to change its
behaviour, which I guessed could be done via ./configure's --prefix
option. But by 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

This is good news because it means I don't have to do anything
explicitly (although its implicit nature confused me) other than to
inform the compiler of the location of any staging directories. It
also means that both the compiles which take place as part of the
./configure as well as the compiles which are done as part of the
build itself (and any compiles that sometimes occur during an
install!) will behave correctly.

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? I noticed, while looking through the "-v" output that
someone is including a --sysroot option implicitly.

Thank you for the detailed explanation of how to work each option (in
addition to listing the options previously).

> Solution two would mean:
>    cp -a $(tuple-gcc --your-cflags-except-sysroot -print-sysroot)  \
>       /path/to/staging
>    ./configure --blabla-as-above                                  \
>                CC="tuple-gcc --syroot=/path/to/staging"           \
>                CXX="tuple-g++ --sysroot=/path/to/staging"         \
>                LD="tuple-ld --sysroot=/path/to/staging"           \
>                AND_SO_ON=tuple-andsoon --sysroot=/path/to/staging"

Very nice, I like this trick (of including the --sysroot as part of
the tool command)! It would save me from caring whether the build
system that comes with the software package handles
CFLAGS/CXXFLAGS/CPPFLAGS/etc... correctly.

Best regards,
    Trevor

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

Re: --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

Re: --host versus --target

[Thomas Petazzoni]

Le Wed, 16 Nov 2011 11:16:08 -0500,
Trevor Woerner <twoerner@gmail.com> a écrit :

> I wasn't aware there existed different strategies for putting together
> a cross-root-filesystem, I'm quite happy you took the time to list
> them. Ironically, looking through the list (and I realize you're not
> going to agree) I think option #1 is the best. Having recently put in
> the time to put together such an image, I can attest it was quite a
> pain getting the various packages to compile correctly.

That's because you shouldn't be doing that manually. There are embedded
Linux build systems that are designed to precisely handle this work.
OpenEmbedded, Yocto, Buildroot, PTXdist, OpenBricks, etc. My preference
of course goes towards Buildroot, since I'm part of the development
team. But the others are fine, too, since they make this
cross-compilation easier *and* reproducible.

Handling the cross-compilation of the various packages for its embedded
Linux system in a manual way is a very bad development practice, in my
opinion.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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