mirror/buildroot
1
0
Fork 0
mirror of https://gitlab.com/buildroot.org/buildroot.git synced 2026-09-30 22:11:59 -09:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit is contained in:
Jerzy Grzegorek
2014-03-28 22:24:50 +01:00
committed by Thomas Petazzoni
parent 6167a2cac6
commit c09dda8e56
4 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/manual/configure.txt
View File

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