docs/manual/configure.txt

30 code for your system. It consists of a compiler (in our case, +gcc+),
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
48 The compilation toolchain is provided by your distribution, and
53 As said above, the compilation toolchain that comes with your system
54 runs on and generates code for the processor in your host system. As
55 your embedded system has a different processor, you need a
57 your _host system_ but generates code for your _target system_ (and
58 target processor). For example, if your host system uses x86 and your
59 target system uses ARM, the regular compilation toolchain on your host
81 applications and libraries for your target embedded system.
101    your toolchain do not need to match _exactly_ the version of the
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
107    your Linux kernel.
138   takes time. If you're trying to reduce your build time, consider
163   where your toolchain is already installed on your system. Just
166   +Toolchain path+ text entry with the path to your cross-compiling
174   to tell Buildroot what your external toolchain supports. If your
176   whether your toolchain supports C\++ or not and whether it has
177   built-in RPC support. If your external toolchain uses the 'uClibc'
199 gcc/binutils/C library installed by your distribution) as the
200 toolchain to build software for the target. This is because your
207 If you want to generate a custom toolchain for your project, that can
224 * If your pre-built external toolchain has a bug, may be hard to get a
225   fix from the toolchain vendor, unless you build your external
238 * Select the appropriate *Target options* for your target CPU
242   for *Toolchain type*, and configure your toolchain as desired
272 * Set *Toolchain URL* to +file:///path/to/your/sdk/tarball.tar.gz+
293 files_, your userspace applications would not be able to use the
315    _device file_ is missing in your system, you can for example create
317    that contains the description of your additional _device files_,
334    charge of building the Linux kernel for your embedded device, it
336    build your Linux kernel outside of Buildroot, then it is your
338    your Buildroot system will not boot).