From efcb3933433838b71f3a4a53ec1ac6d899aaec0b Mon Sep 17 00:00:00 2001 From: Pierre Labastie Date: Sun, 3 May 2020 21:02:51 +0000 Subject: Make the new book git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross-chap5@11831 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/toolchaintechnotes.xml | 445 +++++++++++++++++++++++++++------------ 1 file changed, 307 insertions(+), 138 deletions(-) (limited to 'chapter05/toolchaintechnotes.xml') diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index e0ab899eb..63c9210e5 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -24,143 +24,312 @@ process has been designed to minimize the risks for new readers and to provide the most educational value at the same time. - - Before continuing, be aware of the name of the working platform, - often referred to as the target triplet. A simple way to determine the - name of the target triplet is to run the config.guess - script that comes with the source for many packages. Unpack the Binutils - sources and run the script: ./config.guess and note - the output. For example, for a 32-bit Intel processor the - output will be i686-pc-linux-gnu. On a 64-bit - system it will be x86_64-pc-linux-gnu. - - 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 ld that is part of Binutils). The dynamic linker - provided by 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 will be ld-linux.so.2 (ld-linux-x86-64.so.2 for 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: readelf -l - <name of binary> | grep interpreter and noting the - output. The authoritative reference covering all platforms is in the - shlib-versions file in the root of the Glibc source - tree. - - - Some key technical points of how the build method works: - - - - Slightly adjusting the name of the working platform, by changing the - "vendor" field target triplet by way of the - LFS_TGT variable, ensures that the first build of Binutils - and GCC produces a compatible cross-linker and cross-compiler. Instead of - producing binaries for another architecture, the cross-linker and - cross-compiler will produce binaries compatible with the current - hardware. - - - The temporary libraries are cross-compiled. Because a - cross-compiler by its nature cannot rely on anything from its host - system, this method removes potential contamination of the target - system by lessening the chance of headers or libraries from the host - being incorporated into the new tools. Cross-compilation also allows for - the possibility of building both 32-bit and 64-bit libraries on 64-bit - capable hardware. - - - Careful manipulation of the GCC source tells the compiler which target - dynamic linker will be used. - - - - Binutils is installed first because the configure - 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 first realize. 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. - - Binutils installs its assembler and linker in two locations, - /tools/bin and /tools/$LFS_TGT/bin. 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 - ld by passing it the --verbose - flag. For example, an ld --verbose | grep SEARCH - will illustrate the current search paths and their order. It shows which - files are linked by ld by compiling a dummy program and - passing the --verbose switch to the linker. For example, - gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded - will show all the files successfully opened during the linking. - - The next package installed is GCC. An example of what can be - seen during its run of configure is: - -checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as -checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld - - 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 gcc - itself, the same search paths are not necessarily used. To find out which - standard linker gcc will use, run: - gcc -print-prog-name=ld. - - Detailed information can be obtained from gcc by - passing it the -v command line option while compiling - a dummy program. For example, gcc -v dummy.c will show - detailed information about the preprocessor, compilation, and assembly stages, - including gcc's included search paths and their order. - - Next installed are sanitized Linux API headers. These allow the standard - C library (Glibc) to interface with features that the Linux kernel will - provide. - - The next package installed is 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 --host parameter passed to its - configure script; e.g. in our case, the compiler will be - i686-lfs-linux-gnu-gcc. The binary tools and kernel - headers can be a bit more complicated. Therefore, take no risks and use the - available configure switches to enforce the correct selections. After the run - of configure, check the contents of the - config.make file in the glibc-build directory for all important details. - Note the use of CC="i686-lfs-gnu-gcc" to control which - binary tools are used and the use of the -nostdinc and - -isystem flags to control the compiler's include - search path. These items highlight an important aspect of the Glibc - package—it is very self-sufficient in terms of its build machinery and - generally does not rely on toolchain defaults. - - During the second pass of Binutils, we are able to utilize the - --with-lib-path configure switch to control - ld's library search path. - - For the second pass of GCC, its sources also need to be modified to - tell GCC to use the new dynamic linker. Failure to do so will result in the - GCC programs themselves having the name of the dynamic linker from the host - system's /lib directory embedded into - them, which would defeat the goal of getting away from the host. From this - point onwards, the core toolchain is self-contained and self-hosted. The - remainder of the packages all build - against the new Glibc in /tools. - - Upon entering the chroot environment in , the first major package to be - installed is Glibc, due to its self-sufficient nature mentioned above. - Once this Glibc is installed into /usr, we will perform a quick changeover of the - toolchain defaults, and then proceed in building the rest of the target - LFS system. + The build process is based on the process of + cross-compilation. Cross-compilation is normally used + for building a compiler and its toolchain for a machine different from + the one that is used for the build. This is not strictly needed 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 the great advantage that + anything that is cross-compiled cannot depend on the host environment. + + + + About Cross-Compilation + + Cross-compilation involves some concepts that deserve a section on + their own. Although this section may be omitted in a first reading, it + is strongly suggested to come back to it later in order to get a full + grasp of the build process. + + Let us first define some terms used in this context: + + + build + is the machine where we build programs. Note that this machine + is referred to as the host in other + sections. + + + host + is the machine/system where the built programs will run. Note + that this use of host is not the same as in other + sections. + + + target + is only used for compilers. It is the machine the compiler + produces code for. It may be different from both build and + host. + + + + + As an example, let us imagine the following scenario: we may have a + compiler on a slow machine only, let's call the machine A, and the compiler + ccA. We may have also a fast machine (B), but with no compiler, and we may + want to produce code for a another slow machine (C). Then, to build a + compiler for machine C, we would have three stages: + + + + + + + + + + StageBuildHost + TargetAction + + + + 1AAB + build cross-compiler cc1 using ccA on machine A + + + 2ABB + build cross-compiler cc2 using cc1 on machine A + + + 3BCC + build compiler ccC using cc2 on machine B + + + + + + Then, all the other 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 built programs until machine + C itself is running. For example, for testing ccC, we may want to add a + fourth stage: + + + + + + + + + + StageBuildHost + TargetAction + + + + 4CCC + rebuild and test ccC using itself on machine C + + + + + + 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 native compilers. + + + + + Implementation of Cross-Compilation for LFS + + + Almost all the build systems use names of the form + cpu-vendor-kernel-os referred to as the machine triplet. An astute + reader may wonder why a triplet refers to a four component + name. The reason is history: initially, three component names were enough + to designate unambiguously a machine, but with new machines and systems + appearing, that proved insufficient. The word triplet + remained. A simple way to determine your machine triplet is to run + the config.guess + script that comes with the source for many packages. Unpack the Binutils + sources and run the script: ./config.guess and note + the output. For example, for a 32-bit Intel processor the + output will be i686-pc-linux-gnu. On a 64-bit + system it will be x86_64-pc-linux-gnu. + + 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 ld that is part of Binutils). The dynamic linker + provided by 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 will be ld-linux.so.2 (ld-linux-x86-64.so.2 for 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: readelf -l + <name of binary> | grep interpreter and noting the + output. The authoritative reference covering all platforms is in the + shlib-versions file in the root of the Glibc source + tree. + + + In order to fake a cross compilation, the name of the host triplet + is slightly adjusted by changing the "vendor" field in the + LFS_TGT variable. We also use the + --with-sysroot when building the cross linker and + cross compiler, to tell them where to find the needed host files. This + ensures none of the other programs built in can link to libraries on the build + machine. Only two stages are mandatory, and one more for tests: + + + + + + + + + + StageBuildHost + TargetAction + + + + 1pcpclfs + build cross-compiler cc1 using cc-pc on pc + + + 2pclfslfs + build compiler cc-lfs using cc1 on pc + + + 3lfslfslfs + rebuild and test cc-lfs using itself on lfs + + + + + + In the above table, on pc means the commands are run + on a machine using the already installed distribution. On + lfs means the commands are run in a chrooted environment. + + Now, there is more about cross-compiling: the C language is not + just a compiler, but also defines a standard library. In this book, the + GNU C library, named glibc, is used. This library must + be compiled for the lfs machine, that is, using the cross compiler cc1. + But the compiler itself uses an internal library implementing complex + instructions not available in the assembler instruction set. This + internal library is named libgcc, and must be linked to the glibc + library to be fully functional! Furthermore, the standard library for + C++ (libstdc++) also needs being linked to glibc. The solution + to this chicken and egg problem is to first build a degraded cc1+libgcc, + lacking some fuctionalities such as threads and exception handling, then + build glibc using this degraded compiler (glibc itself is not + degraded), then build libstdc++. But this last library will lack the + same functionalities as libgcc. + + This is not the end of the story: the conclusion of the preceding + paragraph is that cc1 is unable to build a fully functional libstdc++, but + this is the only compiler available for building the C/C++ libraries + during stage 2! Of course, the compiler built during stage 2, cc-lfs, + would be able to build those libraries, but (i) the build system of + gcc does not know that it is usable on pc, and (ii) using it on pc + would be at risk of linking to the pc libraries, since cc-lfs is a native + compiler. So we have to build libstdc++ later, in chroot. + + + + + + Other procedural details + + The cross-compiler will be installed in a separate $LFS/tools directory, since it will not + be part of the final system. + + Binutils is installed first because the configure + 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 first realize. 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. + + Binutils installs its assembler and linker in two locations, + $LFS/tools/bin and $LFS/tools/$LFS_TGT/bin. 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 + ld by passing it the --verbose + flag. For example, $LFS_TGT-ld --verbose | grep SEARCH + will illustrate the current search paths and their order. It shows which + files are linked by ld by compiling a dummy program and + passing the --verbose switch to the linker. For + example, + $LFS_TGT-gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded + will show all the files successfully opened during the linking. + + The next package installed is GCC. An example of what can be + seen during its run of configure is: + +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 + + 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 gcc itself, the same search paths are not + necessarily used. To find out which standard linker gcc + will use, run: $LFS_TGT-gcc -print-prog-name=ld. + + Detailed information can be obtained from gcc by + passing it the -v command line option while compiling + a dummy program. For example, gcc -v dummy.c will show + detailed information about the preprocessor, compilation, and assembly + stages, including gcc's included search paths and their + order. + + Next installed are sanitized Linux API headers. These allow the + standard C library (Glibc) to interface with features that the Linux + kernel will provide. + + The next package installed is 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 --host + parameter passed to its configure script; e.g. in our case, the compiler + will be $LFS_TGT-gcc. The binary tools and kernel + headers can be a bit more complicated. Therefore, take no risks and use + the available configure switches to enforce the correct selections. After + the run of configure, check the contents of the + config.make file in the build directory for all important details. + Note the use of CC="$LFS_TGT-gcc" (with + $LFS_TGT expanded) to control which binary tools are used + and the use of the -nostdinc and + -isystem flags to control the compiler's include + search path. These items highlight an important aspect of the Glibc + package—it is very self-sufficient in terms of its build machinery + and generally does not rely on toolchain defaults. + + As said above, the standard C++ library is compiled next, followed + by all the programs that need themselves to be built. The install step + uses the DESTDIR variable to have the programs land into + the LFS filesystem. + + Then the native lfs compiler is built. First Binutils Pass 2, with + the same DESTDIR install as the other programs, then the + second pass of GCC, omitting libstdc++ and other non-important libraries. + Due to some weird logic in GCC's configure script, + CC_FOR_TARGET ends up as cc when host + is the same as target, but is different from build. This is why + CC_FOR_TARGET=$LFS_TGT-gcc is put explicitely into + the configure options. + + Upon entering the chroot environment in , the first task is to install + libstdc++. Then temporary installations of programs needed for the proper + operation of the toolchain are performed. Programs needed for testing + other programs are also built. From this point onwards, the + core toolchain is self-contained and self-hosted. In the remainder of + the , final versions of all the + packages needed for a fully functional system are built, tested and + installed. + + -- cgit v1.2.3-54-g00ecf From 784dc13f86cceda51ded588831d429a574808720 Mon Sep 17 00:00:00 2001 From: Pierre Labastie Date: Mon, 8 Jun 2020 07:18:58 +0000 Subject: Fix a reference in toolchain notes git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11899 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/toolchaintechnotes.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'chapter05/toolchaintechnotes.xml') diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index 63c9210e5..376337662 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -321,12 +321,12 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld Upon entering the chroot environment in , the first task is to install + linkend="chapter-chroot-temporary-tools"/>, the first task is to install libstdc++. Then temporary installations of programs needed for the proper operation of the toolchain are performed. Programs needed for testing other programs are also built. From this point onwards, the - core toolchain is self-contained and self-hosted. In the remainder of - the , final versions of all the + core toolchain is self-contained and self-hosted. In + , final versions of all the packages needed for a fully functional system are built, tested and installed. -- cgit v1.2.3-54-g00ecf From 79524a0c69fd6f6f1fa86086b86d52328af17750 Mon Sep 17 00:00:00 2001 From: Bruce Dubbs Date: Tue, 9 Jun 2020 23:10:16 +0000 Subject: Text updates for cross2 Chapter 5 git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11914 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter04/aboutsbus.xml | 2 +- chapter05/binutils-pass1.xml | 21 ++++----------- chapter05/gcc-pass1.xml | 33 +++++++++++++++--------- chapter05/generalinstructions.xml | 6 ++--- chapter05/glibc.xml | 4 +-- chapter05/libstdc++.xml | 12 ++++----- chapter05/toolchaintechnotes.xml | 54 ++++++++++++++++++++------------------- stylesheets/lfs-xsl/lfs.css | 2 +- 8 files changed, 67 insertions(+), 67 deletions(-) (limited to 'chapter05/toolchaintechnotes.xml') diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml index 646fe2875..1928423ea 100644 --- a/chapter04/aboutsbus.xml +++ b/chapter04/aboutsbus.xml @@ -41,7 +41,7 @@ compilation time for a package can be reduced by performing a "parallel make" by either setting an environment variable or telling the make program how many processors are available. For - instance, an Intel i5-6500 COU can support four simultaneous processes with: + instance, an Intel i5-6500 CPU can support four simultaneous processes with: export MAKEFLAGS='-j4' diff --git a/chapter05/binutils-pass1.xml b/chapter05/binutils-pass1.xml index e91c64a62..00816c94a 100644 --- a/chapter05/binutils-pass1.xml +++ b/chapter05/binutils-pass1.xml @@ -63,13 +63,10 @@ cd build to be of any use, measure the time it takes to build this package from the configuration, up to and including the first install. To achieve this easily, wrap the commands in a time - command like this: time { ./configure ... && ... + command like this: time { ./configure ... && make && make install; }. - + Now prepare Binutils for compilation: ../configure --prefix=$LFS/tools \ @@ -85,7 +82,7 @@ cd build --prefix=$LFS/tools This tells the configure script to prepare to install the - Binutils programs in the $LFS/tools directory. @@ -97,22 +94,14 @@ cd build $LFS for the target system libraries as needed. - + --target=$LFS_TGT Because the machine description in the LFS_TGT variable is slightly different than the value returned by the config.guess script, this switch will tell the - configure script to adjust Binutil's build system + configure script to adjust binutil's build system for building a cross linker. diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index 7db6408c2..2f8145713 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -131,37 +131,46 @@ cd build + + --enable-initfini-array + + This switch forces the use of some internal data structures + that are needed but cannot be detected when building a cross + compiler. + + + --disable-shared This switch forces GCC to link its internal libraries - statically. We need this because the shared libraries require glibc, - which is not yet installed on the target system. + statically. We need this because the shared libraries require glibc, + which is not yet installed on the target system. + + + + + --disable-multilib + + On x86_64, LFS does not support a multilib configuration. + This switch is harmless for x86. --disable-decimal-float, --disable-threads, - --disable-libatomic, --disable-libgomp, + --disable-libatomic, --disable-libgomp, --disable-libquadmath, --disable-libssp, --disable-libvtv, --disable-libstdcxx These switches disable support for the decimal floating point - extension, threading, libatomic, libgomp, libquadmath, libssp, + extension, threading, libatomic, libgomp, libquadmath, libssp, libvtv, and the C++ standard library respectively. These features will fail to compile when building a cross-compiler and are not necessary for the task of cross-compiling the temporary libc. - - --disable-multilib - - On x86_64, LFS does not yet support a multilib configuration. - This switch is harmless for x86. - - - --enable-languages=c,c++ diff --git a/chapter05/generalinstructions.xml b/chapter05/generalinstructions.xml index 05b88b98c..b0a5377e1 100644 --- a/chapter05/generalinstructions.xml +++ b/chapter05/generalinstructions.xml @@ -18,7 +18,7 @@ Several of the packages are patched before compilation, but only when the patch is needed to circumvent a problem. A patch is often needed in - both this and the next chapter, but sometimes in only one or the other. + both this and the following chapters, but sometimes in only one location. Therefore, do not be concerned if instructions for a downloaded patch seem to be missing. Warning messages about offset or fuzz may also be encountered when applying a patch. Do @@ -93,8 +93,8 @@ Using the tar program, extract the package - to be built. In Chapter 5, ensure you are the lfs - user when extracting the package. + to be built. In Chapters 5 and 6, ensure you are + the lfs user when extracting the package. Change to the directory created when the package was diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml index d6974bb21..361dd0e58 100644 --- a/chapter05/glibc.xml +++ b/chapter05/glibc.xml @@ -211,14 +211,14 @@ readelf -l a.out | grep '/ld-linux' - Building packages in the next sections will serve as an + Building packages in the next chapter will serve as an additional check that the toolchain has been built properly. If some package, especially binutils-pass2 or gcc-pass2, fails to build, it is an indication that something has gone wrong with the previous Binutils, GCC, or Glibc installations. Now that our cross-toolchain is complete, finalize the installation - of the limits.h header. For doing so, run an utility provided by the GCC + of the limits.h header. For doing so, run a utility provided by the GCC developers: $LFS/tools/libexec/gcc/$LFS_TGT/&gcc-version;/install-tools/mkheaders diff --git a/chapter05/libstdc++.xml b/chapter05/libstdc++.xml index 3a1b0f2bf..5058be9a5 100644 --- a/chapter05/libstdc++.xml +++ b/chapter05/libstdc++.xml @@ -53,12 +53,12 @@ gcc-&gcc-version; directory. - Create a separate build directory for Libstdc++ and enter it: + Create a separate build directory for libstdc++ and enter it: mkdir -v build cd build - Prepare Libstdc++ for compilation: + Prepare libstdc++ for compilation: ../libstdc++-v3/configure \ --host=$LFS_TGT \ @@ -75,7 +75,7 @@ cd build --host=... - Indicates to use the cross compiler we have just built + Specifies the use the cross compiler we have just built instead of the one in /usr/bin. @@ -91,9 +91,9 @@ cd build --with-gxx-include-dir=/tools/$LFS_TGT/include/c++/&gcc-version; - This is the location where the standard include files are - searched by the C++ compiler. In a normal build, this information - is automatically passed to the Libstdc++ configure + This is the location where the C++ compiler should search for the + standard include files. In a normal build, this information + is automatically passed to the libstdc++ configure options from the top level directory. In our case, this information must be explicitly given. diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index 376337662..9e582e345 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -16,13 +16,14 @@ clearer after performing an actual build. This section can be referred to at any time during the process. - The overall goal of is to - produce a temporary area that contains a known-good set of tools that can be - isolated from the host system. By using chroot, the - commands in the remaining chapters will be contained 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. + The overall goal of this chapter and is to produce a temporary area that + contains a known-good set of tools that can be isolated from the host system. + By using chroot, the commands in the remaining chapters + will be contained 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. The build process is based on the process of cross-compilation. Cross-compilation is normally used @@ -143,7 +144,7 @@ appearing, that proved insufficient. The word triplet remained. A simple way to determine your machine triplet is to run the config.guess - 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: ./config.guess and note the output. For example, for a 32-bit Intel processor the output will be i686-pc-linux-gnu. On a 64-bit @@ -151,7 +152,7 @@ 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 ld that is part of Binutils). The dynamic linker + linker ld that is part of binutils). The dynamic linker provided by 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 will be In order to fake a cross compilation, the name of the host triplet is slightly adjusted by changing the "vendor" field in the LFS_TGT variable. We also use the - --with-sysroot when building the cross linker and - cross compiler, to tell them where to find the needed host files. This - ensures none of the other programs built in --with-sysroot 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 can link to libraries on the build machine. Only two stages are mandatory, and one more for tests: @@ -215,7 +216,7 @@ internal library is named libgcc, and must be linked to the glibc library to be fully functional! Furthermore, the standard library for C++ (libstdc++) also needs being linked to glibc. The solution - to this chicken and egg problem is to first build a degraded cc1+libgcc, + to this chicken and egg problem is to first build a degraded cc1 based libgcc, lacking some fuctionalities such as threads and exception handling, then build glibc using this degraded compiler (glibc itself is not degraded), then build libstdc++. But this last library will lack the @@ -225,8 +226,8 @@ paragraph is that cc1 is unable to build a fully functional libstdc++, but this is the only compiler available for building the C/C++ libraries during stage 2! Of course, the compiler built during stage 2, cc-lfs, - would be able to build those libraries, but (i) the build system of - gcc does not know that it is usable on pc, and (ii) using it on pc + 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 would be at risk of linking to the pc libraries, since cc-lfs is a native compiler. So we have to build libstdc++ later, in chroot. @@ -306,17 +307,18 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld - As said above, the standard C++ library is compiled next, followed - by all the programs that need themselves to be built. The install step - uses the DESTDIR variable to have the programs land into - the LFS filesystem. - - Then the native lfs compiler is built. First Binutils Pass 2, with - the same DESTDIR install as the other programs, then the - second pass of GCC, omitting libstdc++ and other non-important libraries. - Due to some weird logic in GCC's configure script, - CC_FOR_TARGET ends up as cc when host - is the same as target, but is different from build. This is why + As said above, the standard C++ library is compiled next, followed in + Chapter 6 by all the programs that need themselves to be built. The install + step of libstdc++ uses the DESTDIR variable to have the + programs land into the LFS filesystem. + + In Chapter 7 the native lfs compiler is built. First binutils-pass2, + with the same DESTDIR install as the other programs is + built, and then the second pass of GCC is constructed, omitting libstdc++ + and other non-important libraries. Due to some weird logic in GCC's + configure script, CC_FOR_TARGET ends up as + cc when the host is the same as the target, but is + different from the build system. This is why CC_FOR_TARGET=$LFS_TGT-gcc is put explicitely into the configure options. diff --git a/stylesheets/lfs-xsl/lfs.css b/stylesheets/lfs-xsl/lfs.css index 15ceba1ef..23d461304 100644 --- a/stylesheets/lfs-xsl/lfs.css +++ b/stylesheets/lfs-xsl/lfs.css @@ -342,7 +342,7 @@ div.important em, div.warning em, div.caution em { margin-bottom: .3em; } -.table table { +.table table, .informaltable { margin-left: auto; margin-right: auto; } -- cgit v1.2.3-54-g00ecf From 77d2cd8d437a6ba11e13ac0af109a887582e988b Mon Sep 17 00:00:00 2001 From: Pierre Labastie Date: Sat, 13 Jun 2020 08:55:55 +0000 Subject: - fix some gcc->GCC - remove commented text in glibc (chap 5), and fix a directory location git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11934 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/gcc-pass1.xml | 2 +- chapter05/glibc.xml | 25 ++++--------------------- chapter05/toolchaintechnotes.xml | 2 +- chapter06/gcc-pass2.xml | 2 +- chapter08/libffi.xml | 4 ++-- chapter08/strippingagain.xml | 2 +- 6 files changed, 10 insertions(+), 27 deletions(-) (limited to 'chapter05/toolchaintechnotes.xml') diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index e2a13a003..0cd852ee6 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -193,7 +193,7 @@ cd build headers. Normally one of them, limits.h, would in turn include the corresponding system limits.h header, in this case, $LFS/usr/include/limits.h. However, at the - time of this build of gcc $LFS/usr/include/limits.h + time of this build of GCC $LFS/usr/include/limits.h does not exist, so the internal header that has just been installed is a partial, self-contained file and does not include the extended features of the system header. This is adequate for building glibc, but the full diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml index 6e14f0c7d..1b72b4e20 100644 --- a/chapter05/glibc.xml +++ b/chapter05/glibc.xml @@ -99,9 +99,10 @@ cd build --with-headers=$LFS/usr/include - This tells Glibc to compile itself against the headers recently - installed to the usr/include directory, so that it knows exactly what - features the kernel has and can optimize itself accordingly. + This tells Glibc to compile itself against the headers + recently installed to the $LFS/usr/include directory, so that + it knows exactly what features the kernel has and can optimize + itself accordingly. @@ -112,24 +113,6 @@ cd build of the default /lib64 on 64 bit machines. - diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index 9e582e345..1e7086aaf 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -227,7 +227,7 @@ this is the only compiler available for building the C/C++ libraries during stage 2! Of course, the compiler built during stage 2, cc-lfs, 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 be at risk of linking to the pc libraries, since cc-lfs is a native compiler. So we have to build libstdc++ later, in chroot. diff --git a/chapter06/gcc-pass2.xml b/chapter06/gcc-pass2.xml index 532a8e8b4..c64d6f780 100644 --- a/chapter06/gcc-pass2.xml +++ b/chapter06/gcc-pass2.xml @@ -109,7 +109,7 @@ ln -s ../../../libgcc/gthr-posix.h $LFS_TGT/libgcc/gthr-default.h-with-build-sysroot=$LFS Normally, using --host ensures that - a cross-compiler is used for building gcc, and that compiler knows + a cross-compiler is used for building GCC, and that compiler knows that it has to look for headers and libraries in $LFS. But the build system of GCC uses other tools, which are not aware of this location. This switch is diff --git a/chapter08/libffi.xml b/chapter08/libffi.xml index 3b5347992..b6a49b122 100644 --- a/chapter08/libffi.xml +++ b/chapter08/libffi.xml @@ -60,14 +60,14 @@ --with-gcc-arch=native - Ensure gcc optimizes for the current system. If this + Ensure GCC optimizes for the current system. If this is not specified, the system is guessed and the code generated may not be correct for some systems. If the generated code will be copied from the native system to a less capable system, use the less capable system as a parameter. For details about alternative system types, see - the x86 options in the gcc manual. + the x86 options in the GCC manual. diff --git a/chapter08/strippingagain.xml b/chapter08/strippingagain.xml index d436fcbda..891d2e000 100644 --- a/chapter08/strippingagain.xml +++ b/chapter08/strippingagain.xml @@ -30,7 +30,7 @@ url='&blfs-book;/general/gdb.html'>gdb later in BLFS. - + save_lib="ld-&glibc-version;.so libc-&glibc-version;.so libpthread-&glibc-version;.so libthread_db-&libthread_db-version;.so" -- cgit v1.2.3-54-g00ecf