docs/5 - Using the toolchain.txt
author Trevor Woerner <twoerner@gmail.com>
Wed Nov 16 16:06:42 2011 -0500 (2011-11-16)
changeset 2753 710fa859bfe6
parent 2564 5d4e91c0343e
child 2764 986e90e1ca27
permissions -rw-r--r--
docs: --target versus --host

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. It is
better to use --host.

Signed-off-by: "Trevor Woerner" <twoerner@gmail.com>
[yann.morin.1998@anciens.enib.fr: add build/host clarification]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
     1 File.........: 5 - Using the toolchain.txt
     2 Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
     3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
     4 
     5 
     6 Using the toolchain  /
     7 ____________________/
     8 
     9 
    10 Using the toolchain is as simple as adding the toolchain's bin directory in
    11 your PATH, such as:
    12   export PATH="${PATH}:/your/toolchain/path/bin"
    13 
    14 and then using the '--host' tuple to tell the build systems to use your
    15 toolchain (if the software package uses the autotools system you should
    16 also pass --build, for completeness):
    17   ./configure --host=your-host-tuple --build=your-build-tuple
    18 or
    19   make CC=your-host-tuple-gcc
    20 or
    21   make CROSS_COMPILE=your-host-tuple-
    22 and so on...
    23 
    24 (Note: in the above example, 'host' refers to the host of your program,
    25 not the host of the toolchain; and 'build' refers to the machine where
    26 you build your program, that is the host of the toolchain.)
    27 
    28 It is strongly advised not to use the toolchain sysroot directory as an
    29 install directory for your programs/packages. If you do so, you will not be
    30 able to use your toolchain for another project. It is even strongly advised
    31 that your toolchain is chmod-ed to read-only once successfully build, so that
    32 you don't go polluting your toolchain with your programs/packages' files.
    33 
    34 Thus, when you build a program/package, install it in a separate directory,
    35 eg. /your/root. This directory is the /image/ of what would be in the root file
    36 system of your target, and will contain all that your programs/packages have
    37 installed.
    38 
    39 
    40 The 'populate' script |
    41 ----------------------+
    42 
    43 When your root directory is ready, it is still missing some important bits: the
    44 toolchain's libraries. To populate your root directory with those libs, just
    45 run:
    46   your-target-tuple-populate -s /your/root -d /your/root-populated
    47 
    48 This will copy /your/root into /your/root-populated, and put the needed and only
    49 the needed libraries there. Thus you don't pollute /your/root with any cruft that
    50 would no longer be needed should you have to remove stuff. /your/root always
    51 contains only those things you install in it.
    52 
    53 You can then use /your/root-populated to build up your file system image, a
    54 tarball, or to NFS-mount it from your target, or whatever you need.
    55 
    56 The populate script accepts the following options:
    57 
    58  -s src_dir
    59     Use 'src_dir' as the un-populated root directory.
    60 
    61  -d dst_dir
    62     Put the populated root directory in 'dst_dir'.
    63 
    64  -l lib1 [...]
    65     Always add specified libraries.
    66 
    67  -L file
    68     Always add libraries listed in 'file'.
    69 
    70  -f
    71     Remove 'dst_dir' if it previously existed; continue even if any library
    72     specified with -l or -L is missing.
    73 
    74  -v
    75     Be verbose, and tell what's going on (you can see exactly where libs are
    76     coming from).
    77 
    78  -h
    79     Print the help.
    80 
    81 See 'your-target-tuple-populate -h' for more information on the options.
    82 
    83 Here is how populate works:
    84 
    85   1) performs some sanity checks:
    86      - src_dir and dst_dir are specified
    87      - src_dir exists
    88      - unless forced, dst_dir does not exist
    89      - src_dir != dst_dir
    90 
    91   2) copy src_dir to dst_dir
    92 
    93   3) add forced libraries to dst_dir
    94      - build the list from -l and -L options
    95      - get forced libraries from the sysroot (see below for heuristics)
    96        - abort on the first missing library, unless -f is specified
    97 
    98   4) add all missing libraries to dst_dir
    99      - scan dst_dir for every ELF files that are 'executable' or
   100        'shared object'
   101      - list the "NEEDED Shared library" fields
   102        - check if the library is already in dst_dir/lib or dst_dir/usr/lib
   103        - if not, get the library from the sysroot
   104          - if it's in sysroot/lib, copy it to dst_dir/lib
   105          - if it's in sysroot/usr/lib, copy it to dst_dir/usr/lib
   106          - in both cases, use the SONAME of the library to create the file
   107            in dst_dir
   108          - if it was not found in the sysroot, this is an error.