crosstool-ng/docs/4 - Building the toolchain.txt

File.........: 4 - Building the toolchain.txt
Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.fr>
License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5


Building the toolchain  /
_______________________/


To build the toolchain, simply type:
  ct-ng build

This will use the above configuration to retrieve, extract and patch the
components, build, install and eventually test your newly built toolchain.

You are then free to add the toolchain /bin directory in your PATH to use
it at will.

In any case, you can get some terse help. Just type:
  ct-ng help
or:
  man 1 ct-ng


Stopping and restarting a build |
--------------------------------+

If you want to stop the build after a step you are debugging, you can pass the
variable STOP to make:
  ct-ng build STOP=some_step

Conversely, if you want to restart a build at a specific step you are
debugging, you can pass the RESTART variable to make:
  ct-ng build RESTART=some_step

Alternatively, you can call make with the name of a step to just do that step:
  ct-ng libc_headers
is equivalent to:
  ct-ng build RESTART=libc_headers STOP=libc_headers

The shortcuts +step_name and step_name+ allow to respectively stop or restart
at that step. Thus:
  ct-ng +libc_headers              and:    ct-ng libc_headers+
are equivalent to:
  ct-ng build STOP=libc_headers    and:    ct-ng build RESTART=libc_headers

To obtain the list of acceptable steps, please call:
  ct-ng list-steps

Note that in order to restart a build, you'll have to say 'Y' to the config
option CT_DEBUG_CT_SAVE_STEPS, and that the previous build effectively went
that far.


Building all toolchains at once |
--------------------------------+

You can build all samples; simply call:
  ct-ng build-all


Overriding the number of // jobs |
---------------------------------+

If you want to override the number of jobs to run in // (the -j option to
make), you can either re-enter the menuconfig, or simply add it on the command
line, as such:
  ct-ng build.4

which tells crosstool-NG to override the number of // jobs to 4.

You can see the actions that support overriding the number of // jobs in
the help menu. Those are the ones with [.#] after them (eg. build[.#] or
build-all[.#], and so on...).


Note on // jobs |
----------------+

The crosstool-NG script 'ct-ng' is a Makefile-script. It does *not* execute
in parallel (there is not much to gain). When speaking of // jobs, we are
refering to the number of // jobs when making the *components*. That is, we
speak of the number of // jobs used to build gcc, glibc, and so on...


Tools wrapper |
--------------+

Starting with gcc-4.3 come two new dependencies: GMP and MPFR. With gcc-4.4,
come three new ones: PPL, CLooG/ppl and MPC. With gcc-4.5 again comes a new
dependency on libelf. These are libraries that enable advanced features to
gcc. Additionally, some of those libraries can be used by binutils and gdb.
Unfortunately, not all systems on which crosstool-NG runs have all of those
libraries. And for those that do, the versions of those libraries may be
older than the version required by gcc (and binutils and gdb). To date,
Debian stable (aka Lenny) is lagging behind on some, and is missing the
others. With >= gcc-4.8, we drop PPL and CLooG/PPL, and switch to ISL to
replace PPL, and use the upstream version of CLooG instead of CLooG/PPL
which was a fork of CLooG that provided PPL backend support, that was under-
maintained. See: https://gcc.gnu.org/wiki/Graphite-4.8

This is why crosstool-NG builds its own set of libraries as part of the
toolchain.

The companion libraries can be built either as static libraries, or as shared
libraries. The default is to build static libraries, and is the safe way.
If you decide to use static companion libraries, then you can stop reading
this section.

But if you prefer to have shared libraries, then read on...

Building shared companion libraries poses no problem at build time, as
crosstool-NG correctly points gcc (and binutils and gdb) to the correct
place where our own version of the libraries are installed. But it poses
a problem when gcc et al. are run: the place where the libraries are is most
probably not known to the host dynamic linker. Still worse, if the host system
has its own versions, then ld.so would load the wrong libraries!

So we have to force the dynamic linker to load the correct version. We do this
by using the LD_LIBRARY_PATH variable, that informs the dynamic linker where
to look for shared libraries prior to searching its standard places. But we
can't impose that burden on all the system (because it'd be a nightmare to
configure, and because two toolchains on the same system may use different
versions of the libraries); so we have to do it on a per-toolchain basis.

So we rename all binaries of the toolchain (by adding a dot '.' as their first
character), and add a small program, the so-called "tools wrapper", that
correctly sets LD_LIBRARY_PATH prior to running the real tool.

First, the wrapper was written as a POSIX-compliant shell script. That shell
script is very simple, if not trivial, and works great. The only drawback is
that it does not work on host systems that lack a shell, for example the
MingW32 environment. To solve the issue, the wrapper has been re-written in C,
and compiled at build time. This C wrapper is much more complex than the shell
script, and although it seems to be working, it's been only lightly tested.
Some of the expected short-comings with this C wrapper are;
 - multi-byte file names may not be handled correctly
 - it's really big for what it does

So, the default wrapper installed with your toolchain is the shell script.
If you know that your system is missing a shell, then you shall use the C
wrapper (and report back whether it works, or does not work, for you).

A final word on the subject: do not build shared libraries. Build them
static, and you'll be safe.