2. Linux From Scratch 12.0
3. part3intro_toolchaintechnotes
4. Search

Filters

• Untranslated strings • state:empty
• Unfinished strings • state:<translated
• Translated strings • state:>=translated
• Strings marked for edit • state:needs-editing
• Strings with suggestions • has:suggestion
• Strings with variants • has:variant
• Strings with screenshots • has:screenshot
• Strings with labels • has:label
• Strings with context • has:context
• Unfinished strings without suggestions • state:<translated AND NOT has:suggestion
• Strings with comments • has:comment
• Strings with any failing checks • has:check
• Approved strings • state:approved
• Strings waiting for review • state:translated

state:empty

Position and priority

• Position and priority
• Position
• Priority
• Labels
• Source string
• Target string
• String age
• Last updated
• Number of words
• Number of comments
• Number of failing checks
• Key
• String location

	Translation	Source string	Target string
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Toolchain Technical Notes
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	This section explains some of the rationale and technical details behind the overall build method. Don't try to immediately understand everything in this section. Most of this information will be clearer after performing an actual build. Come back and re-read this chapter at any time during the build process.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The overall goal of <xref linkend="chapter-cross-tools"/> and <xref linkend="chapter-temporary-tools"/> is to produce a temporary area containing a set of tools that are known to be good, and that are isolated from the host system. By using the <command>chroot</command> command, the compilations in the remaining chapters will be isolated within that environment, ensuring a clean, trouble-free build of the target LFS system. The build process has been designed to minimize the risks for new readers, and to provide the most educational value at the same time.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	This build process is based on <emphasis>cross-compilation</emphasis>. Cross-compilation is normally used to build a compiler and its associated toolchain for a machine different from the one that is used for the build. This is not strictly necessary for LFS, since the machine where the new system will run is the same as the one used for the build. But cross-compilation has one great advantage: anything that is cross-compiled cannot depend on the host environment.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	About Cross-Compilation
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	The LFS book is not (and does not contain) a general tutorial to build a cross- (or native) toolchain. Don't use the commands in the book for a cross-toolchain for some purpose other than building LFS, unless you really understand what you are doing.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The LFS book is not (and does not contain) a general tutorial to build a cross- (or native) toolchain. Don't use the commands in the book for a cross-toolchain for some purpose other than building LFS, unless you really understand what you are doing.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Cross-compilation involves some concepts that deserve a section of their own. Although this section may be omitted on a first reading, coming back to it later will help you gain a fuller understanding of the process.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Let us first define some terms used in this context.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The build
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	is the machine where we build programs. Note that this machine is also referred to as the <quote>host</quote>.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The host
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	is the machine/system where the built programs will run. Note that this use of <quote>host</quote> is not the same as in other sections.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The target
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	is only used for compilers. It is the machine the compiler produces code for. It may be different from both the build and the host.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	As an example, let us imagine the following scenario (sometimes referred to as <quote>Canadian Cross</quote>). We have a compiler on a slow machine only, let's call it machine A, and the compiler ccA. We also have a fast machine (B), but no compiler for (B), and we want to produce code for a third, slow machine (C). We will build a compiler for machine C in three stages.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Stage
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Build
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Host
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Target
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Action
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	1
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	A
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	B
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Build cross-compiler cc1 using ccA on machine A.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	2
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	C
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Build cross-compiler cc2 using cc1 on machine A.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	3
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Build compiler ccC using cc2 on machine B.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Then, all the programs needed by machine C can be compiled using cc2 on the fast machine B. Note that unless B can run programs produced for C, there is no way to test the newly built programs until machine C itself is running. For example, to run a test suite on ccC, we may want to add a fourth stage:
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	4
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Rebuild and test ccC using ccC on machine C.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	In the example above, only cc1 and cc2 are cross-compilers, that is, they produce code for a machine different from the one they are run on. The other compilers ccA and ccC produce code for the machine they are run on. Such compilers are called <emphasis>native</emphasis> compilers.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Implementation of Cross-Compilation for LFS
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	All the cross-compiled packages in this book use an autoconf-based building system. The autoconf-based building system accepts system types in the form cpu-vendor-kernel-os, referred to as the system triplet. Since the vendor field is often irrelevant, autoconf lets you omit it.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	All the cross-compiled packages in this book use an autoconf-based building system. The autoconf-based building system accepts system types in the form cpu-vendor-kernel-os, referred to as the system triplet. Since the vendor field is often irrelevant, autoconf lets you omit it.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	An astute reader may wonder why a <quote>triplet</quote> refers to a four component name. The kernel field and the os field began as a single <quote>system</quote> field. Such a three-field form is still valid today for some systems, for example, <literal>x86_64-unknown-freebsd</literal>. But two systems can share the same kernel and still be too different to use the same triplet to describe them. For example, Android running on a mobile phone is completely different from Ubuntu running on an ARM64 server, even though they are both running on the same type of CPU (ARM64) and using the same kernel (Linux).
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	An astute reader may wonder why a <quote>triplet</quote> refers to a four component name. The kernel field and the os field began as a single <quote>system</quote> field. Such a three-field form is still valid today for some systems, for example, <literal>x86_64-unknown-freebsd</literal>. But two systems can share the same kernel and still be too different to use the same triplet to describe them. For example, Android running on a mobile phone is completely different from Ubuntu running on an ARM64 server, even though they are both running on the same type of CPU (ARM64) and using the same kernel (Linux).
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	Without an emulation layer, you cannot run an executable for a server on a mobile phone or vice versa. So the <quote>system</quote> field has been divided into kernel and os fields, to designate these systems unambiguously. In 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>.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Without an emulation layer, you cannot run an executable for a server on a mobile phone or vice versa. So the <quote>system</quote> field has been divided into kernel and os fields, to designate these systems unambiguously. In 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>.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	The word <quote>triplet</quote> remains embedded in the lexicon. 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 sources, run the script <userinput>./config.guess</userinput>, and note the output. For example, for a 32-bit Intel processor the output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>. On most Linux systems the even simpler <command>gcc -dumpmachine</command> command will give you similar information.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The word <quote>triplet</quote> remains embedded in the lexicon. 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 sources, run the script <userinput>./config.guess</userinput>, and note the output. For example, for a 32-bit Intel processor the output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>. On most Linux systems the even simpler <command>gcc -dumpmachine</command> command will give you similar information.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	You should also be aware of the name of the platform's dynamic linker, often referred to as the dynamic loader (not to be confused with the standard linker <command>ld</command> that is part of binutils). The dynamic linker provided by package glibc finds and loads the shared libraries needed by a program, prepares the program to run, and then runs it. The name of the dynamic linker for a 32-bit Intel machine is <filename class="libraryfile">ld-linux.so.2</filename>; it's <filename class="libraryfile">ld-linux-x86-64.so.2</filename> on 64-bit systems. A sure-fire way to determine the name of the dynamic linker is to inspect a random binary from the host system by running: <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput> and noting the output. The authoritative reference covering all platforms is in the <filename>shlib-versions</filename> file in the root of the glibc source tree.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	In order to fake a cross-compilation in LFS, the name of the host triplet is slightly adjusted by changing the &quot;vendor&quot; field in the <envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use the <parameter>--with-sysroot</parameter> option when building the cross-linker and cross-compiler, to tell them where to find the needed host files. This ensures that none of the other programs built in <xref linkend="chapter-temporary-tools"/> can link to libraries on the build machine. Only two stages are mandatory, plus one more for tests.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	pc
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	lfs
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Build cross-compiler cc1 using cc-pc on pc.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Build compiler cc-lfs using cc1 on pc.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Rebuild and test cc-lfs using cc-lfs on lfs.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	In the preceding table, <quote>on pc</quote> means the commands are run on a machine using the already installed distribution. <quote>On lfs</quote> means the commands are run in a chrooted environment.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	This is not yet the end of the story. The C language is not merely a compiler; it also defines a standard library. In this book, the GNU C library, named glibc, is used (there is an alternative, &quot;musl&quot;). This library must be compiled for the LFS machine; that is, using the cross-compiler cc1. But the compiler itself uses an internal library providing complex subroutines for functions not available in the assembler instruction set. This internal library is named libgcc, and it must be linked to the glibc library to be fully functional. Furthermore, the standard library for C++ (libstdc++) must also be linked with glibc. The solution to this chicken and egg problem is first to build a degraded cc1-based libgcc, lacking some functionalities such as threads and exception handling, and then to build glibc using this degraded compiler (glibc itself is not degraded), and also to build libstdc++. This last library will lack some of the functionality of libgcc.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The upshot of the preceding paragraph is that cc1 is unable to build a fully functional libstdc++ with the degraded libgcc, but cc1 is the only compiler available for building the C/C++ libraries during stage 2. There are two reasons we don't immediately use the compiler built in stage 2, cc-lfs, to build those libraries.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	Generally speaking, cc-lfs cannot run on pc (the host system). Even though the triplets for pc and lfs are compatible with each other, an executable for lfs must depend on glibc-&glibc-version;; the host distro may utilize either a different implementation of libc (for example, musl), or a previous release of glibc (for example, glibc-2.13).
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Generally speaking, cc-lfs cannot run on pc (the host system). Even though the triplets for pc and lfs are compatible with each other, an executable for lfs must depend on glibc-&glibc-version;; the host distro may utilize either a different implementation of libc (for example, musl), or a previous release of glibc (for example, glibc-2.13).
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	Even if cc-lfs can run on pc, using it on pc would create a risk of linking to the pc libraries, since cc-lfs is a native compiler.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Even if cc-lfs can run on pc, using it on pc would create a risk of linking to the pc libraries, since cc-lfs is a native compiler.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	So when we build gcc stage 2, we instruct the building system to rebuild libgcc and libstdc++ with cc1, but we link libstdc++ to the newly rebuilt libgcc instead of the old, degraded build. This makes the rebuilt libstdc++ fully functional.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	So when we build gcc stage 2, we instruct the building system to rebuild libgcc and libstdc++ with cc1, but we link libstdc++ to the newly rebuilt libgcc instead of the old, degraded build. This makes the rebuilt libstdc++ fully functional.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Chinese (Simplified Han script)	In &ch-final; (or <quote>stage 3</quote>), all the packages needed for the LFS system are built. Even if a package has already been installed into the LFS system in a previous chapter, we still rebuild the package. The main reason for rebuilding these packages is to make them stable: if we reinstall an LFS package on a completed LFS system, the reinstalled content of the package should be the same as the content of the same package when first installed in &ch-final;. The temporary packages installed in &ch-tmp-cross; or &ch-tmp-chroot; cannot satisfy this requirement, because some of them are built without optional dependencies, 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 to run the test suites.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	In &ch-final; (or <quote>stage 3</quote>), all the packages needed for the LFS system are built. Even if a package has already been installed into the LFS system in a previous chapter, we still rebuild the package. The main reason for rebuilding these packages is to make them stable: if we reinstall an LFS package on a completed LFS system, the reinstalled content of the package should be the same as the content of the same package when first installed in &ch-final;. The temporary packages installed in &ch-tmp-cross; or &ch-tmp-chroot; cannot satisfy this requirement, because some of them are built without optional dependencies, 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 to run the test suites.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Other Procedural Details
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The cross-compiler will be installed in a separate <filename class="directory">$LFS/tools</filename> directory, since it will not be part of the final system.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Binutils is installed first because the <command>configure</command> runs of both gcc and glibc perform various feature tests on the assembler and linker to determine which software features to enable or disable. This is more important than one might realize at first. An incorrectly configured gcc or glibc can result in a subtly broken toolchain, where the impact of such breakage might not show up until near the end of the build of an entire distribution. A test suite failure will usually highlight this error before too much additional work is performed.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Binutils installs its assembler and linker in two locations, <filename class="directory">$LFS/tools/bin</filename> and <filename class="directory">$LFS/tools/$LFS_TGT/bin</filename>. The tools in one location are hard linked to the other. An important facet of the linker is its library search order. Detailed information can be obtained from <command>ld</command> by passing it the <parameter>--verbose</parameter> flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command> will illustrate the current search paths and their order. (Note that this example can be run as shown only while logged in as user <systemitem class="username">lfs</systemitem>. If you come back to this page later, replace <command>$LFS_TGT-ld</command> with <command>ld</command>).
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	The next package installed is gcc. An example of what can be seen during its run of <command>configure</command> is:
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	<computeroutput>checking what assembler to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/as checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	This is important for the reasons mentioned above. It also demonstrates that gcc's configure script does not search the PATH directories to find which tools to use. However, during the actual operation of <command>gcc</command> itself, the same search paths are not necessarily used. To find out which standard linker <command>gcc</command> will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. (Again, remove the <command>$LFS_TGT-</command> prefix if coming back to this later.)
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Detailed information can be obtained from <command>gcc</command> by passing it the <parameter>-v</parameter> command line option while compiling a program. For example, <command>$LFS_TGT-gcc -v <replaceable>example.c</replaceable></command> (or without <command> $LFS_TGT-</command> if coming back later) will show detailed information about the preprocessor, compilation, and assembly stages, including <command>gcc</command>'s search paths for included headers and their order.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Next up: sanitized Linux API headers. These allow the standard C library (glibc) to interface with features that the Linux kernel will provide.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Next comes glibc. The most important considerations for building glibc are the compiler, binary tools, and kernel headers. The compiler is generally not an issue since glibc will always use the compiler relating to the <parameter>--host</parameter> parameter passed to its configure script; e.g., in our case, the compiler will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel headers can be a bit more complicated. Therefore, we take no risks and use the available configure switches to enforce the correct selections. After the run of <command>configure</command>, check the contents of the <filename>config.make</filename> file in the <filename class="directory">build</filename> directory for all important details. Note the use of <parameter>CC="$LFS_TGT-gcc"</parameter> (with <envar>$LFS_TGT</envar> expanded) to control which binary tools are used and the use of the <parameter>-nostdinc</parameter> and <parameter>-isystem</parameter> flags to control the compiler's include search path. These items highlight an important aspect of the glibc package&mdash;it is very self-sufficient in terms of its build machinery, and generally does not rely on toolchain defaults.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	As mentioned above, the standard C++ library is compiled next, followed in <xref linkend="chapter-temporary-tools"/> by other programs that must be cross-compiled to break circular dependencies at build time. The install step of all those packages uses the <envar>DESTDIR</envar> variable to force installation in the LFS filesystem.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	At the end of <xref linkend="chapter-temporary-tools"/> the native LFS compiler is installed. First binutils-pass2 is built, in the same <envar>DESTDIR</envar> directory as the other programs, then the second pass of gcc is constructed, omitting some non-critical libraries. Due to some weird logic in gcc's configure script, <envar>CC_FOR_TARGET</envar> ends up as <command>cc</command> when the host is the same as the target, but different from the build system. This is why <parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter> is declared explicitly as one of the configuration options.
	Linux From Scratch 12.0/part3intro_toolchaintechnotes — Greek	Upon entering the chroot environment in <xref linkend="chapter-chroot-temporary-tools"/>, the temporary installations of programs needed for the proper operation of the toolchain are performed. From this point onwards, the core toolchain is self-contained and self-hosted. In <xref linkend="chapter-building-system"/>, final versions of all the packages needed for a fully functional system are built, tested, and installed.