Re: --host versus --target

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

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