Changeset d11d449
- Timestamp:
- 09/30/2022 04:12:01 PM (18 months ago)
- Branches:
- 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, bdubbs/gcc13, multilib, renodr/libudev-from-systemd, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- 52ddd6c
- Parents:
- 488b43a (diff), 543c94c (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
general.ent
r488b43a rd11d449 124 124 <!ENTITY fstab "<filename>/etc/fstab</filename>"> 125 125 <!ENTITY boot-dir "<filename class='directory'>/boot</filename>"> 126 <!ENTITY ch-final "<xref linkend='chapter-building-system'/>"> 127 <!ENTITY ch-tmp-cross "<xref linkend='chapter-temporary-tools'/>"> 128 <!ENTITY ch-tmp-chroot "<xref linkend='chapter-chroot-temporary-tools'/>"> 126 129 127 130 <!ENTITY % packages-entities SYSTEM "packages.ent"> -
part3intro/toolchaintechnotes.xml
r488b43a rd11d449 146 146 147 147 <note> 148 <para>Almost all the build systems use names of the form 149 cpu-vendor-kernel-os, referred to as the machine triplet. (Sometimes, 150 the vendor field is omitted.) An astute 151 reader may wonder why a <quote>triplet</quote> refers to a four component 152 name. The reason is historical: initially, three component names were enough 153 to designate a machine unambiguously, but as new machines and systems 154 proliferated, that proved insufficient. The word <quote>triplet</quote> 155 remained. A simple way to determine your machine triplet is to run 156 the <command>config.guess</command> 148 <para>All packages involved with cross compilation in the book use an 149 autoconf-based building system. The autoconf-based building system 150 accepts system types in the form cpu-vendor-kernel-os, 151 referred to as the system triplet. Since the vendor field is mostly 152 irrelevant, autoconf allows to omit it. An astute reader may wonder 153 why a <quote>triplet</quote> refers to a four component name. The 154 reason is the kernel field and the os field originiated from one 155 <quote>system</quote> field. Such a three-field form is still valid 156 today for some systems, for example 157 <literal>x86_64-unknown-freebsd</literal>. But for other systems, 158 two systems can share the same kernel but still be too different to 159 use a same triplet for them. For example, an Android running on a 160 mobile phone is completely different from Ubuntu running on an ARM64 161 server, despite they are running on the same type of CPU (ARM64) and 162 using the same kernel (Linux). 163 Without an emulation layer, you cannot run an 164 executable for the server on the mobile phone or vice versa. So the 165 <quote>system</quote> field is separated into kernel and os fields to 166 designate these systems unambiguously. For our example, the Android 167 system is designated <literal>aarch64-unknown-linux-android</literal>, 168 and the Ubuntu system is designated 169 <literal>aarch64-unknown-linux-gnu</literal>. The word 170 <quote>triplet</quote> remained. A simple way to determine your 171 system triplet is to run the <command>config.guess</command> 157 172 script that comes with the source for many packages. Unpack the binutils 158 173 sources and run the script: <userinput>./config.guess</userinput> and note … … 242 257 gcc does not know that it is usable on pc, and (2) using it on pc 243 258 would create a risk of linking to the pc libraries, since cc-lfs is a native 244 compiler. So we have to re-build libstdc++ twice later on: as a part of 245 gcc stage 2, and then again in the chroot environment (gcc stage 3).</para> 259 compiler. So we have to re-build libstdc++ later as a part of 260 gcc stage 2.</para> 261 262 <para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for 263 the LFS system are built. Even if a package is already installed into 264 the LFS system in a previous chapter, we still rebuild the package 265 unless we are completely sure it's unnecessary. The main reason for 266 rebuilding these packages is to settle them down: if we reinstall a LFS 267 package on a complete LFS system, the installed content of the package 268 should be same as the content of the same package installed in 269 &ch-final;. The temporary packages installed in &ch-tmp-cross; or 270 &ch-tmp-chroot; cannot satisify this expectation because some of them 271 are built without optional dependencies installed, and autoconf cannot 272 perform some feature checks in &ch-tmp-cross; because of cross 273 compilation, causing the temporary packages to lack optional features 274 or use suboptimal code routines. Additionally, a minor reason for 275 rebuilding the packages is allowing to run the testsuite.</para> 246 276 247 277 </sect2>
Note:
See TracChangeset
for help on using the changeset viewer.