gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-19 03:39:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'trunk' of git.linuxfromscratch.org:lfs into trunk

Browse Source
This commit is contained in:
Bruce Dubbs 2022-09-30 11:12:01 -05:00
commit d11d449565
2 changed files with 44 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
general.ent
View File

@ -123,6 +123,9 @@
<!ENTITY lfs-user "<systemitem class='username'>lfs</systemitem>"> <!ENTITY lfs-user "<systemitem class='username'>lfs</systemitem>">
<!ENTITY fstab "<filename>/etc/fstab</filename>"> <!ENTITY fstab "<filename>/etc/fstab</filename>">
<!ENTITY boot-dir "<filename class='directory'>/boot</filename>"> <!ENTITY boot-dir "<filename class='directory'>/boot</filename>">
<!ENTITY ch-final "<xref linkend='chapter-building-system'/>">
<!ENTITY ch-tmp-cross "<xref linkend='chapter-temporary-tools'/>">
<!ENTITY ch-tmp-chroot "<xref linkend='chapter-chroot-temporary-tools'/>">
<!ENTITY % packages-entities SYSTEM "packages.ent"> <!ENTITY % packages-entities SYSTEM "packages.ent">
%packages-entities; %packages-entities;

52
part3intro/toolchaintechnotes.xml
View File

@ -145,15 +145,30 @@
<title>Implementation of Cross-Compilation for LFS</title> <title>Implementation of Cross-Compilation for LFS</title>
<note> <note>
<para>Almost all the build systems use names of the form <para>All packages involved with cross compilation in the book use an
cpu-vendor-kernel-os, referred to as the machine triplet. (Sometimes, autoconf-based building system. The autoconf-based building system
the vendor field is omitted.) An astute accepts system types in the form cpu-vendor-kernel-os,
reader may wonder why a <quote>triplet</quote> refers to a four component referred to as the system triplet. Since the vendor field is mostly
name. The reason is historical: initially, three component names were enough irrelevant, autoconf allows to omit it. An astute reader may wonder
to designate a machine unambiguously, but as new machines and systems why a <quote>triplet</quote> refers to a four component name. The
proliferated, that proved insufficient. The word <quote>triplet</quote> reason is the kernel field and the os field originiated from one
remained. A simple way to determine your machine triplet is to run <quote>system</quote> field. Such a three-field form is still valid
the <command>config.guess</command> today for some systems, for example
<literal>x86_64-unknown-freebsd</literal>. But for other systems,
two systems can share the same kernel but still be too different to
use a same triplet for them. For example, an Android running on a
mobile phone is completely different from Ubuntu running on an ARM64
server, despite they are running on the same type of CPU (ARM64) and
using the same kernel (Linux).
Without an emulation layer, you cannot run an
executable for the server on the mobile phone or vice versa. So the
<quote>system</quote> field is separated into kernel and os fields to
designate these systems unambiguously. For our example, the Android
system is designated <literal>aarch64-unknown-linux-android</literal>,
and the Ubuntu system is designated
<literal>aarch64-unknown-linux-gnu</literal>. The word
<quote>triplet</quote> remained. A simple way to determine your
system triplet is to run the <command>config.guess</command>
script that comes with the source for many packages. Unpack the binutils script that comes with the source for many packages. Unpack the binutils
sources and run the script: <userinput>./config.guess</userinput> and note sources and run the script: <userinput>./config.guess</userinput> and note
the output. For example, for a 32-bit Intel processor the the output. For example, for a 32-bit Intel processor the
@ -241,8 +256,23 @@
would be able to build those libraries, but (1) the build system of would be able to build those libraries, but (1) the build system of
gcc does not know that it is usable on pc, and (2) using it on pc gcc does not know that it is usable on pc, and (2) using it on pc
would create a risk of linking to the pc libraries, since cc-lfs is a native would create a risk of linking to the pc libraries, since cc-lfs is a native
compiler. So we have to re-build libstdc++ twice later on: as a part of compiler. So we have to re-build libstdc++ later as a part of
gcc stage 2, and then again in the chroot environment (gcc stage 3).</para> gcc stage 2.</para>
<para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for
the LFS system are built. Even if a package is already installed into
the LFS system in a previous chapter, we still rebuild the package
unless we are completely sure it's unnecessary. The main reason for
rebuilding these packages is to settle them down: if we reinstall a LFS
package on a complete LFS system, the installed content of the package
should be same as the content of the same package installed in
&ch-final;. The temporary packages installed in &ch-tmp-cross; or
&ch-tmp-chroot; cannot satisify this expectation because some of them
are built without optional dependencies installed, and autoconf cannot
perform some feature checks in &ch-tmp-cross; because of cross
compilation, causing the temporary packages to lack optional features
or use suboptimal code routines. Additionally, a minor reason for
rebuilding the packages is allowing to run the testsuite.</para>
</sect2> </sect2>