|
|
@@ -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
|
Jerzy Grzegorek