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.
|
+make+ command. By default, empty.
|
||||||
|
|
||||||
* +LIBFOO_AUTORECONF+, tells whether the package should
|
* +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,
|
Makefile.in files should be re-generated by re-running autoconf,
|
||||||
automake, libtool, etc.). Valid values are +YES+ and
|
automake, libtool, etc.). Valid values are +YES+ and
|
||||||
+NO+. By default, the value is +NO+
|
+NO+. By default, the value is +NO+
|
||||||
|
|
|
@ -82,7 +82,7 @@ most important ones allow to:
|
||||||
built. This library provides the interface between userspace
|
built. This library provides the interface between userspace
|
||||||
applications and the Linux kernel. In order to know how to "talk"
|
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
|
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
|
define the interface between userspace and the kernel (system
|
||||||
calls, data structures, etc.). Since this interface is backward
|
calls, data structures, etc.). Since this interface is backward
|
||||||
compatible, the version of the Linux kernel headers used to build
|
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.
|
* Change the version of the GCC compiler, binutils and the C library.
|
||||||
|
|
||||||
* Select a number of toolchain options (uClibc only): whether the
|
* 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
|
larger than 2 GB on 32 bits systems), IPv6 support, RPC support
|
||||||
(used mainly for NFS), wide-char support, locale support (for
|
(used mainly for NFS), wide-char support, locale support (for
|
||||||
internationalization), C\++ support or thread support. Depending on
|
internationalization), C\++ support or thread support. Depending on
|
||||||
|
@ -180,17 +180,17 @@ Buildroot itself. In general, all toolchains that support the
|
||||||
developers.
|
developers.
|
||||||
|
|
||||||
We do not support toolchains or SDK generated by OpenEmbedded or
|
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
|
compiler, binutils, the C and C++ libraries). Instead these toolchains
|
||||||
come with a very large set of pre-compiled libraries and
|
come with a very large set of pre-compiled libraries and
|
||||||
programs. Therefore, Buildroot cannot import the 'sysroot' of the
|
programs. Therefore, Buildroot cannot import the 'sysroot' of the
|
||||||
toolchain, as it would contain hundreds of megabytes of pre-compiled
|
toolchain, as it would contain hundreds of megabytes of pre-compiled
|
||||||
libraries that are normally built by Buildroot.
|
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
|
gcc/binutils/C library installed by your distribution) as the
|
||||||
toolchain to build software for the target. This is because your
|
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
|
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
|
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
|
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
|
* The first solution is *Static using device table*. This is the old
|
||||||
classical way of handling device files in Linux. With this method,
|
classical way of handling device files in Linux. With this method,
|
||||||
the device files are persistently stored in the root filesystem
|
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
|
automatically create and remove those device files when hardware
|
||||||
devices are added or removed from the system. Buildroot therefore
|
devices are added or removed from the system. Buildroot therefore
|
||||||
creates a standard set of device files using a _device table_, the
|
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
|
directories called +board/<boardname>/+ under +BR2_EXTERNAL+. This
|
||||||
matches the directory structure used within Buildroot.
|
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
|
+<packagename>.mk+), or even custom configuration options and make
|
||||||
logic. Buildroot automatically includes +BR2_EXTERNAL/Config.in+ to
|
logic. Buildroot automatically includes +BR2_EXTERNAL/Config.in+ to
|
||||||
make it appear in the top-level configuration menu, and includes
|
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
|
* When a package is unselected from the configuration, it is not
|
||||||
sufficient to remove just the files it installed. One must also
|
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
|
and rebuild all those packages. For example, package A depends
|
||||||
optionally on the OpenSSL library. Both are selected, and Buildroot
|
optionally on the OpenSSL library. Both are selected, and Buildroot
|
||||||
is built. Package A is built with crypto support using OpenSSL.
|
is built. Package A is built with crypto support using OpenSSL.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user