manual: fix typo in abbreviation 'i.e.'
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit is contained in:
parent
6167a2cac6
commit
c09dda8e56
|
@ -119,7 +119,7 @@ cases, typical packages will therefore only use a few of them.
|
|||
+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+
|
||||
|
|
|
@ -82,7 +82,7 @@ most important ones allow to:
|
|||
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
|
||||
|
@ -97,7 +97,7 @@ most important ones allow to:
|
|||
* 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
|
||||
|
@ -180,17 +180,17 @@ Buildroot itself. In general, all toolchains that support the
|
|||
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
|
||||
|
@ -235,7 +235,7 @@ different solutions to handle the +/dev+ directory :
|
|||
* 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
|
||||
|
|
|
@ -78,7 +78,7 @@ Or disable the usage of external definitions:
|
|||
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
|
||||
|
|
|
@ -138,7 +138,7 @@ is much more complicated than that:
|
|||
|
||||
* 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.
|
||||
|
|
Loading…
Reference in a new issue