manual: fix typo in abbreviation 'i.e.'

  +make+ command. By default, empty.

* +LIBFOO_AUTORECONF+, tells whether the package should

  be autoreconfigured or not (i.e, if the configure script and

  be autoreconfigured or not (i.e. if the configure script and

  Makefile.in files should be re-generated by re-running autoconf,

  automake, libtool, etc.). Valid values are +YES+ and

  +NO+. By default, the value is +NO+

   built. This library provides the interface between userspace

   applications and the Linux kernel. In order to know how to "talk"

   to the Linux kernel, the C library needs to have access to the

   _Linux kernel headers_ (i.e, the +.h+ files from the kernel), which

   _Linux kernel headers_ (i.e. the +.h+ files from the kernel), which

   define the interface between userspace and the kernel (system

   calls, data structures, etc.). Since this interface is backward

   compatible, the version of the Linux kernel headers used to build

 * Change the version of the GCC compiler, binutils and the C library.

 * Select a number of toolchain options (uClibc only): whether the

   toolchain should have largefile support (i.e support for files

   toolchain should have largefile support (i.e. support for files

   larger than 2 GB on 32 bits systems), IPv6 support, RPC support

   (used mainly for NFS), wide-char support, locale support (for

   internationalization), C\++ support or thread support. Depending on

developers.

We do not support toolchains or SDK generated by OpenEmbedded or

Yocto, because these toolchains are not pure toolchains (i.e just the

Yocto, because these toolchains are not pure toolchains (i.e. just the

compiler, binutils, the C and C++ libraries). Instead these toolchains

come with a very large set of pre-compiled libraries and

programs. Therefore, Buildroot cannot import the 'sysroot' of the

toolchain, as it would contain hundreds of megabytes of pre-compiled

libraries that are normally built by Buildroot.

We also do not support using the distribution toolchain (i.e the

We also do not support using the distribution toolchain (i.e. the

gcc/binutils/C library installed by your distribution) as the

toolchain to build software for the target. This is because your

distribution toolchain is not a "pure" toolchain (i.e only with the

distribution toolchain is not a "pure" toolchain (i.e. only with the

C/C++ library), so we cannot import it properly into the Buildroot

build environment. So even if you are building a system for a x86 or

x86_64 target, you have to generate a cross-compilation toolchain with

 * The first solution is *Static using device table*. This is the old

   classical way of handling device files in Linux. With this method,

   the device files are persistently stored in the root filesystem

   (i.e they persist accross reboots), and there is nothing that will

   (i.e. they persist accross reboots), and there is nothing that will

   automatically create and remove those device files when hardware

   devices are added or removed from the system. Buildroot therefore

   creates a standard set of device files using a _device table_, the

   directories called +board/<boardname>/+ under +BR2_EXTERNAL+. This

   matches the directory structure used within Buildroot.

 * One can store package recipes (i.e +Config.in+ and

 * One can store package recipes (i.e. +Config.in+ and

   +<packagename>.mk+), or even custom configuration options and make

   logic. Buildroot automatically includes +BR2_EXTERNAL/Config.in+ to

   make it appear in the top-level configuration menu, and includes

 * When a package is unselected from the configuration, it is not

   sufficient to remove just the files it installed. One must also

   remove all its reverse dependencies (i.e packages relying on it)

   remove all its reverse dependencies (i.e. packages relying on it)

   and rebuild all those packages. For example, package A depends

   optionally on the OpenSSL library. Both are selected, and Buildroot

   is built. Package A is built with crypto support using OpenSSL.