Changeset 673b0d8 for chapter05/chapter05.xml
- Timestamp:
- 05/03/2004 10:59:46 AM (20 years ago)
- Branches:
- 10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, 6.0, 6.1, 6.1.1, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.5-systemd, 7.6, 7.6-systemd, 7.7, 7.7-systemd, 7.8, 7.8-systemd, 7.9, 7.9-systemd, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, v5_1, v5_1_1, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- 0c43171, 2ec64b3, a4a675f
- Parents:
- 287ea55
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter05/chapter05.xml
r287ea55 r673b0d8 1 <?xml version="1.0" encoding="ISO-8859-1"?> 2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ 3 <!ENTITY % general-entities SYSTEM "../general.ent"> 4 %general-entities; 5 ]> 1 6 <chapter id="chapter-temporary-tools" xreflabel="Chapter 5"> 7 <?dbhtml dir="chapter05"?> 2 8 <title>Constructing a temporary system</title> 3 <?dbhtml filename="chapter05.html" dir="chapter05"?>9 <?dbhtml filename="chapter05.html"?> 4 10 5 6 <sect1 id="ch-tools-introduction"> 7 <title>Introduction</title> 8 <?dbhtml filename="introduction.html" dir="chapter05"?> 9 10 <para>In this chapter we will compile and install a minimal 11 Linux system. This system will contain just enough tools to be able 12 to start constructing the final LFS system in the next chapter.</para> 13 14 <para>The building of this minimal system is done in two steps: first we 15 build a brand-new and host-independent toolchain (compiler, assembler, 16 linker and libraries), and then use this to build all the other essential 17 tools.</para> 18 19 <para>The files compiled in this chapter will be installed under the 20 <filename class="directory">$LFS/tools</filename> directory 21 to keep them separate from the files installed in the next chapter. 22 Since the packages compiled here are merely temporary, we don't want 23 them to pollute the soon-to-be LFS system.</para> 24 25 <para>Before issuing the build instructions for a package you are expected to 26 have already unpacked it as user <emphasis>lfs</emphasis>, and to have 27 performed a <userinput>cd</userinput> into the created directory. The build 28 instructions assume that you are using the <command>bash</command> 29 shell.</para> 30 31 <para>Several of the packages are patched before compilation, but only when 32 the patch is needed to circumvent a problem. Often the patch is needed in 33 both this and the next chapter, but sometimes in only one of them. Therefore, 34 don't worry when instructions for a downloaded patch seem to be missing. Also, 35 when applying a patch, you'll occasionally see warning messages about 36 <emphasis>offset</emphasis> or <emphasis>fuzz</emphasis>. These warnings are 37 nothing to worry about, as the patch was still successfully applied.</para> 38 39 <para>During the compilation of most packages you will see many warnings 40 scroll by on your screen. These are normal and can safely be ignored. They are 41 just what they say they are: warnings -- mostly about deprecated, but not 42 invalid, use of the C or C++ syntax. It's just that C standards have changed 43 rather often and some packages still use the older standard, which is not 44 really a problem.</para> 45 46 <para>After installing each package you should delete its source and build 47 directories, <emphasis>unless</emphasis> told otherwise. Deleting the sources 48 saves space, but also prevents misconfiguration when the same package is 49 reinstalled further on. Only for three packages you will need to keep the 50 source and build directories around for a while, so their contents can be used 51 by later commands. Do not miss the reminders.</para> 52 53 </sect1> 54 55 56 <sect1 id="tools-technicalnotes"> 57 <title>Technical notes</title> 58 <?dbhtml filename="technicalnotes.html" dir="chapter05"?> 59 60 <para>This section attempts to explain some of the rationale and technical 61 details behind the overall build method. It's not essential that you understand 62 everything here immediately. Most of it will make sense once you have performed 63 an actual build. Feel free to refer back here at any time.</para> 64 65 <para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to provide a sane, 66 temporary environment that we can chroot into, and from which we can produce a 67 clean, trouble-free build of the target LFS system in 68 <xref linkend="chapter-building-system"/>. Along the way, we attempt to divorce ourselves 69 from the host system as much as possible, and in so doing build a 70 self-contained and self-hosted toolchain. It should be noted that the 71 build process has been designed in such a way so as to minimize the risks for 72 new readers and provide maximum educational value at the same time. In other 73 words, more advanced techniques could be used to build the system.</para> 74 75 <important> 76 <para>Before continuing, you really should be aware of the name of your working 77 platform, often also referred to as the <emphasis>target triplet</emphasis>. For 78 many folks the target triplet will probably be 79 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target 80 triplet is to run the <filename>config.guess</filename> script that comes with 81 the source for many packages. Unpack the Binutils sources and run the script: 82 <userinput>./config.guess</userinput> and note the output.</para> 83 84 <para>You'll also need to be aware of the name of your platform's 85 <emphasis>dynamic linker</emphasis>, often also referred to as the 86 <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker 87 <emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided 88 by Glibc and has the job of finding and loading the shared libraries needed by a 89 program, preparing the program to run and then running it. For most folks the 90 name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On 91 platforms that are less prevalent, the name might be 92 <emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have 93 something completely different. You should be able to determine the name 94 of your platform's dynamic linker by looking in the 95 <filename class="directory">/lib</filename> directory on your host system. A 96 surefire way is to inspect a random binary from your host system by running: 97 <userinput>readelf -l <name of binary> | grep interpreter</userinput> 98 and noting the output. The authoritative reference covering all platforms is in 99 the <filename>shlib-versions</filename> file in the root of the Glibc source 100 tree.</para> 101 </important> 102 103 <para>Some key technical points of how the <xref linkend="chapter-temporary-tools"/> build 104 method works:</para> 105 106 <itemizedlist> 107 <listitem><para>Similar in principle to cross compiling whereby tools installed 108 into the same prefix work in cooperation and thus utilize a little GNU 109 "magic".</para></listitem> 110 111 <listitem><para>Careful manipulation of the standard linker's library search 112 path to ensure programs are linked only against libraries we 113 choose.</para></listitem> 114 115 <listitem><para>Careful manipulation of <command>gcc</command>'s 116 <emphasis>specs</emphasis> file to tell the compiler which target dynamic 117 linker will be used.</para></listitem> 118 </itemizedlist> 119 120 <para>Binutils is installed first because both GCC and Glibc perform various 121 feature tests on the assembler and linker during their respective runs of 122 <command>./configure</command> to determine which software features to enable 123 or disable. This is more important than one might first realize. An incorrectly 124 configured GCC or Glibc can result in a subtly broken toolchain where the impact 125 of such breakage might not show up until near the end of the build of a whole 126 distribution. Thankfully, a test suite failure will usually alert us before too 127 much time is wasted.</para> 128 129 <para>Binutils installs its assembler and linker into two locations, 130 <filename class="directory">/tools/bin</filename> and 131 <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality, 132 the tools in one location are hard linked to the other. An important facet of 133 the linker is its library search order. Detailed information can be obtained 134 from <command>ld</command> by passing it the <emphasis>--verbose</emphasis> 135 flag. For example: <command>ld --verbose | grep SEARCH</command> will 136 show you the current search paths and their order. You can see what files are 137 actually linked by <command>ld</command> by compiling a dummy program and 138 passing the <emphasis>--verbose</emphasis> switch to the linker. For example: 139 <command>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</command> 140 will show you all the files successfully opened during the linking.</para> 141 142 <para>The next package installed is GCC and during its run of 143 <command>./configure</command> you'll see, for example:</para> 144 145 <blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as 146 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote> 147 148 <para>This is important for the reasons mentioned above. It also demonstrates 149 that GCC's configure script does not search the PATH directories to find which 150 tools to use. However, during the actual operation of <command>gcc</command> 151 itself, the same search paths are not necessarily used. You can find out which 152 standard linker <command>gcc</command> will use by running: 153 <command>gcc -print-prog-name=ld</command>. 154 Detailed information can be obtained from <command>gcc</command> by passing 155 it the <emphasis>-v</emphasis> flag while compiling a dummy program. For 156 example: <command>gcc -v dummy.c</command> will show you detailed 157 information about the preprocessor, compilation and assembly stages, including 158 <command>gcc</command>'s include search paths and their order.</para> 159 160 <para>The next package installed is Glibc. The most important considerations for 161 building Glibc are the compiler, binary tools and kernel headers. The compiler 162 is generally no problem as Glibc will always use the <command>gcc</command> 163 found in a PATH directory. The binary tools and kernel headers can be a little 164 more troublesome. Therefore we take no risks and use the available configure 165 switches to enforce the correct selections. After the run of 166 <command>./configure</command> you can check the contents of the 167 <filename>config.make</filename> file in the 168 <filename class="directory">glibc-build</filename> directory for all the 169 important details. You'll note some interesting items like the use of 170 <emphasis>CC="gcc -B/tools/bin/"</emphasis> to control which binary tools are 171 used, and also the use of the <emphasis>-nostdinc</emphasis> and 172 <emphasis>-isystem</emphasis> flags to control the compiler's include search 173 path. These items help to highlight an important aspect of the Glibc package: 174 it is very self-sufficient in terms of its build machinery and generally does 175 not rely on toolchain defaults.</para> 176 177 <para>After the Glibc installation, we make some adjustments to ensure that 178 searching and linking take place only within our <filename>/tools</filename> 179 prefix. We install an adjusted <command>ld</command>, which has a hard-wired 180 search path limited to <filename class="directory">/tools/lib</filename>. Then 181 we amend <command>gcc</command>'s specs file to point to our new dynamic 182 linker in <filename class="directory">/tools/lib</filename>. This last step is 183 <emphasis>vital</emphasis> to the whole process. As mentioned above, a 184 hard-wired path to a dynamic linker is embedded into every ELF shared 185 executable. You can inspect this by running: 186 <command>readelf -l <name of binary> | grep interpreter</command>. 187 By amending <command>gcc</command>'s specs file, we are ensuring that every 188 program compiled from here through the end of this chapter will use our new 189 dynamic linker in <filename class="directory">/tools/lib</filename>.</para> 190 191 <para>The need to use the new dynamic linker is also the reason why we apply the 192 Specs patch for the second pass of GCC. Failure to do so will result in the GCC 193 programs themselves having the name of the dynamic linker from the host system's 194 <filename class="directory">/lib</filename> directory embedded into them, which 195 would defeat our goal of getting away from the host.</para> 196 197 <para>During the second pass of Binutils, we are able to utilize the 198 <emphasis>--with-lib-path</emphasis> configure switch to control 199 <command>ld</command>'s library search path. From this point onwards, the 200 core toolchain is self-contained and self-hosted. The remainder of the 201 <xref linkend="chapter-temporary-tools"/> packages all build against the new Glibc in 202 <filename class="directory">/tools</filename> and all is well.</para> 203 204 <para>Upon entering the chroot environment in <xref linkend="chapter-building-system"/>, the 205 first major package we install is Glibc, due to its self-sufficient nature that 206 we mentioned above. Once this Glibc is installed into 207 <filename class="directory">/usr</filename>, we perform a quick changeover of 208 the toolchain defaults, then proceed for real in building the rest of the 209 target LFS system.</para> 210 211 </sect1> 212 213 214 <sect1 id="tools-aboutlinking"> 215 <title>Notes on static linking</title> 216 <?dbhtml filename="aboutlinking.html" dir="chapter05"?> 217 218 <para>Most programs have to perform, beside their specific task, many rather 219 common and sometimes trivial operations. These include allocating memory, 220 searching directories, reading and writing files, string handling, pattern 221 matching, arithmetic and many other tasks. Instead of obliging each program to 222 reinvent the wheel, the GNU system provides all these basic functions in 223 ready-made libraries. The major library on any Linux system is 224 <emphasis>Glibc</emphasis>.</para> 225 226 <para>There are two primary ways of linking the functions from a library to a 227 program that uses them: statically or dynamically. When a program is linked 228 statically, the code of the used functions is included in the executable, 229 resulting in a rather bulky program. When a program is dynamically linked, what 230 is included is a reference to the dynamic linker, the name of the library, and 231 the name of the function, resulting in a much smaller executable. (A third way 232 is to use the programming interface of the dynamic linker. See the 233 <emphasis>dlopen</emphasis> man page for more information.)</para> 234 235 <para>Dynamic linking is the default on Linux and has three major advantages 236 over static linking. First, you need only one copy of the executable library 237 code on your hard disk, instead of having many copies of the same code included 238 into a whole bunch of programs -- thus saving disk space. Second, when several 239 programs use the same library function at the same time, only one copy of the 240 function's code is required in core -- thus saving memory space. Third, when a 241 library function gets a bug fixed or is otherwise improved, you only need to 242 recompile this one library, instead of having to recompile all the programs that 243 make use of the improved function.</para> 244 245 <para>If dynamic linking has several advantages, why then do we statically link 246 the first two packages in this chapter? The reasons are threefold: historical, 247 educational, and technical. Historical, because earlier versions of LFS 248 statically linked every program in this chapter. Educational, because knowing 249 the difference is useful. Technical, because we gain an element of independence 250 from the host in doing so, meaning that those programs can be used 251 independently of the host system. However, it's worth noting that an overall 252 successful LFS build can still be achieved when the first two packages are 253 built dynamically.</para> 254 255 </sect1> 256 257 258 &c5-binutils-pass1; 259 &c5-gcc-pass1; 260 &c5-kernelheaders; 261 &c5-glibc; 262 263 264 <sect1 id="ch-tools-adjusting"> 265 <title>Adjusting the toolchain</title> 266 <?dbhtml filename="adjusting.html" dir="chapter05"?> 267 268 <para>Now that the temporary C libraries have been installed, we want all 269 the tools compiled in the rest of this chapter to be linked against these 270 libraries. To accomplish this, we need to adjust the linker and the compiler's 271 specs file. Some people would say that it is <emphasis>"black magic juju below 272 this line"</emphasis>, but it is really very simple.</para> 273 274 <para>First install the adjusted linker (adjusted at the end of the first pass 275 of Binutils) by running the following command from within 276 the <filename class="directory">binutils-build</filename> directory:</para> 277 278 <screen><userinput>make -C ld install</userinput></screen> 279 280 <para>From this point onwards everything will link <emphasis>only</emphasis> 281 against the libraries in <filename>/tools/lib</filename>.</para> 282 283 <note><para>If you somehow missed the earlier warning to retain the Binutils 284 source and build directories from the first pass or otherwise accidentally 285 deleted them or just don't have access to them, don't worry, all is not lost. 286 Just ignore the above command. The result is a small chance of the subsequent 287 testing programs linking against libraries on the host. This is not ideal, but 288 it's not a major problem. The situation is corrected when we install the 289 second pass of Binutils a bit further on.</para></note> 290 291 <para>Now that the adjusted linker is installed, you have to 292 <emphasis>remove</emphasis> the Binutils build and source directories.</para> 293 294 <para>The next thing to do is to amend our GCC specs file so that it points 295 to the new dynamic linker. A simple sed will accomplish this:</para> 296 297 <!-- Ampersands are needed to allow cut and paste --> 298 299 <screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs && 300 sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \ 301 $SPECFILE > tempspecfile && 302 mv -f tempspecfile $SPECFILE && 303 unset SPECFILE</userinput></screen> 304 305 <para>We recommend that you cut-and-paste the above rather than try and type it 306 all in. Or you can edit the specs file by hand if you want to: just replace the 307 occurrence of "/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2". Be sure to 308 visually inspect the specs file to verify the intended change was actually 309 made.</para> 310 311 <important><para>If you are working on a platform where the name of the dynamic 312 linker is something other than <filename>ld-linux.so.2</filename>, you 313 <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the 314 name of your platform's dynamic linker in the above commands. Refer back to 315 <xref linkend="tools-technicalnotes"/> if necessary.</para></important> 316 317 <para>Lastly, there is a possibility that some include files from the host 318 system have found their way into GCC's private include dir. This can happen 319 because of GCC's "fixincludes" process which runs as part of the GCC build. 320 We'll explain more about this further on in this chapter. For now, run the 321 following commands to eliminate this possibility:</para> 322 323 <screen><userinput>rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen> 324 325 <!-- HACK - Force some whitespace to appease tidy --> 326 <literallayout></literallayout> 327 328 <caution><para>It is imperative at this point to stop and ensure that the basic 329 functions (compiling and linking) of the new toolchain are working as expected. 330 For this we are going to perform a simple sanity check:</para> 331 332 <screen><userinput>echo 'main(){}' > dummy.c 333 cc dummy.c 334 readelf -l a.out | grep ': /tools'</userinput></screen> 335 336 <para>If everything is working correctly, there should be no errors, and the 337 output of the last command will be (allowing for platform specific differences 338 in dynamic linker name):</para> 339 340 <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote> 341 342 <para>Note especially that <filename class="directory">/tools/lib</filename> 343 appears as the prefix of our dynamic linker.</para> 344 345 <para>If you did not receive the output 346 as shown above, or received no output at all, then something is seriously wrong. 347 You will need to investigate and retrace your steps to find out where the 348 problem is and correct it. There is no point in continuing until this is done. 349 First, redo the sanity check using <command>gcc</command> instead of 350 <command>cc</command>. If this works it means the 351 <filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit 352 <xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your PATH 353 is correct. You can check this by running <userinput>echo $PATH</userinput> and 354 verifying that <filename class="directory">/tools/bin</filename> is at the head 355 of the list. If the PATH is wrong it could mean you're not logged in as user 356 <emphasis>lfs</emphasis> or something went wrong back in <xref 357 linkend="prepare-settingenvironment"/>. Third, something may have gone wrong 358 with the specs file amendment above. In this case redo the specs file amendment 359 ensuring to cut-and-paste the commands as was recommended.</para> 360 361 <para>Once you are satisfied that all is well, clean up the test files:</para> 362 363 <screen><userinput>rm dummy.c a.out</userinput></screen> 364 </caution> 365 366 <!-- HACK - Force some whitespace to appease tidy --> 367 <literallayout></literallayout> 368 369 </sect1> 370 371 372 &c5-tcl; 373 &c5-expect; 374 &c5-dejagnu; 375 &c5-gcc-pass2; 376 &c5-binutils-pass2; 377 378 &c5-gawk; 379 &c5-coreutils; 380 &c5-bzip2; 381 &c5-gzip; 382 &c5-diffutils; 383 &c5-findutils; 384 &c5-make; 385 &c5-grep; 386 &c5-sed; 387 &c5-gettext; 388 &c5-ncurses; 389 &c5-patch; 390 &c5-tar; 391 &c5-texinfo; 392 &c5-bash; 393 &c5-perl; 394 395 396 <sect1 id="ch-tools-stripping"> 397 <title>Stripping</title> 398 <?dbhtml filename="stripping.html" dir="chapter05"?> 399 400 <para>The steps in this section are optional, but if your LFS partition is 401 rather small, you will be glad to learn that you can remove some unnecessary 402 things. The executables and libraries you have built so far contain about 130 403 MB of unneeded debugging symbols. Remove those symbols with:</para> 404 405 <screen><userinput>strip --strip-debug /tools/lib/* 406 strip --strip-unneeded /tools/{,s}bin/*</userinput></screen> 407 408 <para>The last of the above commands will skip some twenty files, reporting 409 that it doesn't recognize their file format. Most of them are scripts instead 410 of binaries.</para> 411 412 <para>Take care <emphasis>not</emphasis> to use 413 <emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones 414 would be destroyed and you would have to build the three toolchain packages 415 all over again.</para> 416 417 <para>To save another 30 MB, you can remove all the documentation:</para> 418 419 <screen><userinput>rm -rf /tools/{doc,info,man}</userinput></screen> 420 421 <para>You will now need to have at least 850 MB of free space on your LFS 422 file system to be able to build and install Glibc in the next phase. If you can 423 build and install Glibc, you can build and install the rest too.</para> 424 425 </sect1> 11 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="introduction.xml"/> 12 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="toolchaintechnotes.xml"/> 13 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="binutils-pass1.xml"/> 14 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gcc-pass1.xml"/> 15 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="kernel-headers.xml"/> 16 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="glibc.xml"/> 17 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="adjusting.xml"/> 18 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="tcl.xml"/> 19 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="expect.xml"/> 20 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="dejagnu.xml"/> 21 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gcc-pass2.xml"/> 22 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="binutils-pass2.xml"/> 23 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gawk.xml"/> 24 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="coreutils.xml"/> 25 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="bzip2.xml"/> 26 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gzip.xml"/> 27 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="diffutils.xml"/> 28 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="findutils.xml"/> 29 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="make.xml"/> 30 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="grep.xml"/> 31 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="sed.xml"/> 32 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gettext.xml"/> 33 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="ncurses.xml"/> 34 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="patch.xml"/> 35 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="tar.xml"/> 36 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="texinfo.xml"/> 37 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="bash.xml"/> 38 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="util-linux.xml"/> 39 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="perl.xml"/> 40 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="stripping.xml"/> 426 41 427 42 </chapter> 428
Note:
See TracChangeset
for help on using the changeset viewer.