toolchaintechnotes: Typos

Just found the typos translating my own words :(.
This commit is contained in:
Xi Ruoyao 2025-03-27 23:30:41 +08:00
parent 576a368232
commit 8cd3ab533d
No known key found for this signature in database
GPG Key ID: ACAAD20E19E710E3
2 changed files with 6 additions and 6 deletions

View File

@ -252,7 +252,7 @@ SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib");</computeroutput></screen>
<para>A 32-bit system may use a few other directories, but anyway
the important facet here is all the pathes should begin with an equal sign
the important facet here is all the paths should begin with an equal sign
(<literal>=</literal>), which would be replaced with the sysroot
directory that we've configured for the linker.</para>

View File

@ -245,7 +245,8 @@
example, when building an utility natively, its man page can be
generated by running the utility with the
<parameter>--help</parameter> switch and processing the output,
but generally it's not possible to do so as the utility may fail
but generally it's not possible to do so for a cross-compilation
as the utility may fail
to run on <quote>the build</quote>: it's obviously impossible to
run ARM64 machine code on a x86 CPU (without an emulator).
</para>
@ -253,7 +254,7 @@
With an autoconf-based build system, this requirement is
satisfied in <quote>the cross-compilation mode</quote> where
the optional features requiring to run machine code for
<quote>the host</quote> are disabled. When <quote>the
<quote>the host</quote> during the build time are disabled. When <quote>the
host</quote> triplet is explicitly specified, <quote>the
cross-compilation mode</quote> is enabled if and only if either
the <command>configure</command> script fails to run a dummy
@ -302,7 +303,7 @@
<command>libtool</command>, a <quote>compatibility</quote> wrapper of
the compiler and the linker for autoconf-based build systems,
can try to be too clever and mistakenly pass options allowing the linker
to find libraries of <quote>the host.</quote>
to find libraries of <quote>the build.</quote>
To prevent this fallout, we need to delete the libtool archive
(<filename class='extension'>.la</filename>) files and fix up an
outdated libtool copy shipped with the Binutils code.</para>
@ -360,8 +361,7 @@
during stage 2. As we've discussed, we cannot run cc-lfs on pc (the
host distro) because it may require some library, code, or data not
available on <quote>the build</quote> (the host distro).
So when we build gcc stage 2, we instruct the building system to
rebuild libgcc and libstdc++ with cc1, but we also override the library
So when we build gcc stage 2, we override the library
search path to link libstdc++ against the newly
rebuilt libgcc instead of the old, degraded build. This makes the rebuilt
libstdc++ fully functional.</para>