yann@2076: File.........: 4 - Building the toolchain.txt yann@2908: Copyright....: (C) 2010 Yann E. MORIN yann@2076: License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5 yann@2076: yann@2076: yann@2076: Building the toolchain / yann@2076: _______________________/ yann@2076: yann@2076: yann@2076: To build the toolchain, simply type: yann@2076: ct-ng build yann@2076: yann@2076: This will use the above configuration to retrieve, extract and patch the yann@2076: components, build, install and eventually test your newly built toolchain. yann@2076: yann@2076: You are then free to add the toolchain /bin directory in your PATH to use yann@2076: it at will. yann@2076: yann@2076: In any case, you can get some terse help. Just type: yann@2076: ct-ng help yann@2076: or: yann@2076: man 1 ct-ng yann@2076: yann@2076: yann@2076: Stopping and restarting a build | yann@2076: --------------------------------+ yann@2076: yann@2076: If you want to stop the build after a step you are debugging, you can pass the yann@2076: variable STOP to make: yann@2076: ct-ng build STOP=some_step yann@2076: yann@2076: Conversely, if you want to restart a build at a specific step you are yann@2076: debugging, you can pass the RESTART variable to make: yann@2076: ct-ng build RESTART=some_step yann@2076: yann@2076: Alternatively, you can call make with the name of a step to just do that step: yann@2076: ct-ng libc_headers yann@2076: is equivalent to: yann@2076: ct-ng build RESTART=libc_headers STOP=libc_headers yann@2076: yann@2076: The shortcuts +step_name and step_name+ allow to respectively stop or restart yann@2076: at that step. Thus: yann@2076: ct-ng +libc_headers and: ct-ng libc_headers+ yann@2076: are equivalent to: yann@2076: ct-ng build STOP=libc_headers and: ct-ng build RESTART=libc_headers yann@2076: yann@2076: To obtain the list of acceptable steps, please call: yann@2076: ct-ng list-steps yann@2076: yann@2076: Note that in order to restart a build, you'll have to say 'Y' to the config yann@2076: option CT_DEBUG_CT_SAVE_STEPS, and that the previous build effectively went yann@2076: that far. yann@2076: yann@2076: yann@2076: Building all toolchains at once | yann@2076: --------------------------------+ yann@2076: yann@2076: You can build all samples; simply call: yann@2076: ct-ng build-all yann@2076: yann@2076: yann@2076: Overriding the number of // jobs | yann@2076: ---------------------------------+ yann@2076: yann@2076: If you want to override the number of jobs to run in // (the -j option to yann@2076: make), you can either re-enter the menuconfig, or simply add it on the command yann@2076: line, as such: yann@2076: ct-ng build.4 yann@2076: yann@2076: which tells crosstool-NG to override the number of // jobs to 4. yann@2076: yann@2076: You can see the actions that support overriding the number of // jobs in yann@2076: the help menu. Those are the ones with [.#] after them (eg. build[.#] or yann@2076: build-all[.#], and so on...). yann@2076: yann@2076: yann@2076: Note on // jobs | yann@2076: ----------------+ yann@2076: yann@2076: The crosstool-NG script 'ct-ng' is a Makefile-script. It does *not* execute yann@2076: in parallel (there is not much to gain). When speaking of // jobs, we are yann@2076: refering to the number of // jobs when making the *components*. That is, we yann@2076: speak of the number of // jobs used to build gcc, glibc, and so on... yann@2076: yann@2076: yann@2076: Tools wrapper | yann@2076: --------------+ yann@2076: yann@2076: Starting with gcc-4.3 come two new dependencies: GMP and MPFR. With gcc-4.4, yann@2076: come three new ones: PPL, CLooG/ppl and MPC. With gcc-4.5 again comes a new yann@2076: dependency on libelf. These are libraries that enable advanced features to yann@2076: gcc. Additionally, some of those libraries can be used by binutils and gdb. yann@2076: Unfortunately, not all systems on which crosstool-NG runs have all of those yann@2076: libraries. And for those that do, the versions of those libraries may be yann@2076: older than the version required by gcc (and binutils and gdb). To date, yann@2076: Debian stable (aka Lenny) is lagging behind on some, and is missing the yann@2076: others. yann@2076: yann@2076: This is why crosstool-NG builds its own set of libraries as part of the yann@2076: toolchain. yann@2076: yann@2076: The companion libraries can be built either as static libraries, or as shared yann@2076: libraries. The default is to build static libraries, and is the safe way. yann@2076: If you decide to use static companion libraries, then you can stop reading yann@2076: this section. yann@2076: yann@2076: But if you prefer to have shared libraries, then read on... yann@2076: yann@2076: Building shared companion libraries poses no problem at build time, as yann@2076: crosstool-NG correctly points gcc (and binutils and gdb) to the correct yann@2076: place where our own version of the libraries are installed. But it poses yann@2076: a problem when gcc et al. are run: the place where the libraries are is most yann@2076: probably not known to the host dynamic linker. Still worse, if the host system yann@2076: has its own versions, then ld.so would load the wrong libraries! yann@2076: yann@2076: So we have to force the dynamic linker to load the correct version. We do this yann@2076: by using the LD_LIBRARY_PATH variable, that informs the dynamic linker where yann@2076: to look for shared libraries prior to searching its standard places. But we yann@2076: can't impose that burden on all the system (because it'd be a nightmare to yann@2076: configure, and because two toolchains on the same system may use different yann@2076: versions of the libraries); so we have to do it on a per-toolchain basis. yann@2076: yann@2076: So we rename all binaries of the toolchain (by adding a dot '.' as their first yann@2076: character), and add a small program, the so-called "tools wrapper", that yann@2076: correctly sets LD_LIBRARY_PATH prior to running the real tool. yann@2076: yann@2076: First, the wrapper was written as a POSIX-compliant shell script. That shell yann@2076: script is very simple, if not trivial, and works great. The only drawback is yann@2076: that it does not work on host systems that lack a shell, for example the yann@2076: MingW32 environment. To solve the issue, the wrapper has been re-written in C, yann@2076: and compiled at build time. This C wrapper is much more complex than the shell antony@2564: script, and although it seems to be working, it's been only lightly tested. yann@2076: Some of the expected short-comings with this C wrapper are; yann@2076: - multi-byte file names may not be handled correctly yann@2076: - it's really big for what it does yann@2076: yann@2076: So, the default wrapper installed with your toolchain is the shell script. yann@2076: If you know that your system is missing a shell, then you shall use the C yann@2076: wrapper (and report back whether it works, or does not work, for you). yann@2076: yann@2076: A final word on the subject: do not build shared libraries. Build them yann@2076: static, and you'll be safe.