docs/manual/configure.txt

1 // -*- mode:doc; -*-
23 sufficiently self-explanatory, a number of topics require additional
27 === Cross-compilation toolchain
34 http://www.uclibc-ng.org/[uClibc-ng]).
36 The system installed on your development station certainly already has
38 that runs on your system. If you're using a PC, your compilation
39 toolchain runs on an x86 processor and generates code for an x86
42 toolchain is called the "host compilation toolchain". The machine on
43 which it is running, and on which you're working, is called the "host
45 configure, where the host is the machine on which the application will
50 cross-compilation toolchain and other tools that are run on the
54 runs on and generates code for the processor in your host system. As
56 cross-compilation toolchain - a compilation toolchain that runs on
59 target system uses ARM, the regular compilation toolchain on your host
60 runs on x86 and generates code for x86, while the cross-compilation
61 toolchain runs on x86 and generates code for ARM.
63 Buildroot provides two solutions for the cross-compilation toolchain:
76 [[internal-toolchain-backend]]
80 by itself a cross-compilation toolchain, before building the userspace
84 http://www.uclibc-ng.org[uClibc-ng],
86 http://www.musl-libc.org[musl].
93    building a cross-compilation toolchain, the C library is being
102    Linux kernel you intend to run on your embedded system. They only
105    recent than the Linux kernel you run on your embedded system, then
113    wide-char support, locale support (for internationalization),
114    C++ support or thread support. Depending on which options you choose,
120    configuration by running +make uclibc-menuconfig+. Note however that
128 xref:full-rebuild[].
141 [[external-toolchain-backend]]
144 The _external toolchain backend_ allows to use existing pre-built
145 cross-compilation toolchains. Buildroot knows about a number of
146 well-known cross-compilation toolchains (from
148 http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/[So…
149 CodeBench] for ARM, x86-64, PowerPC, and MIPS, and is capable of
163   where your toolchain is already installed on your system. Just
166   +Toolchain path+ text entry with the path to your cross-compiling
170   useful for toolchains generated using crosstool-NG or with Buildroot
177   built-in RPC support. If your external toolchain uses the 'uClibc'
179   wide-char, locale, program invocation, threads and C++.
185 http://crosstool-ng.org[crosstool-NG], and toolchains generated by
193 come with a very large set of pre-compiled libraries and
195 toolchain, as it would contain hundreds of megabytes of pre-compiled
204 x86_64 target, you have to generate a cross-compilation toolchain with
205 Buildroot or crosstool-NG.
210 xref:build-toolchain-with-buildroot[]) or with
211 http://crosstool-ng.org[crosstool-NG].
215 * Allows to use well-known and well-tested cross-compilation
218 * Avoids the build time of the cross-compilation toolchain, which is
224 * If your pre-built external toolchain has a bug, may be hard to get a
226   toolchain by yourself using Buildroot or Crosstool-NG.
228 [[build-toolchain-with-buildroot]]
255 -----
257 -----
260 +arm-buildroot-linux-uclibcgnueabi_sdk-buildroot.tar.gz+. Save this
261 tarball, as it is now the toolchain that you can re-use as an external
284 * +1+: trace all arguments on a single line
290 On a Linux system, the +/dev+ directory contains special files, called
322    xref:makedev-syntax[].
341    also relies on the _devtmpfs_ virtual filesystem detailed above (so
344    apply), but adds the +mdev+ userspace utility on top of it. +mdev+
348    specific permissions or ownership on a device file, call a script
350    etc. Basically, it allows _userspace_ to react on device addition
352    load kernel modules when devices appear on the system. +mdev+ is
361    method also relies on the _devtmpfs_ virtual filesystem detailed
362    above, but adds the +eudev+ userspace daemon on top of it. +eudev+
363    is a daemon that runs in the background, and gets called by the
418    D-Bus activation for starting services, offers on-demand starting
421    etc. +systemd+ will be useful on relatively complex embedded
422    systems, for example the ones requiring D-Bus and services