- Timestamp:
- 11/13/2003 10:31:08 PM (21 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, 12.2, 12.2-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/loongarch-12.2, xry111/mips64el, xry111/multilib, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- d322394
- Parents:
- 0ba2766b
- Location:
- chapter05
- Files:
-
- 6 deleted
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter05/chapter05.xml
r0ba2766b rcfabeed 3 3 <?dbhtml filename="chapter05.html" dir="chapter05"?> 4 4 5 &c5-introduction; 6 &c5-toolchaintechnotes; 7 &c5-creatingtoolsdir; 8 &c5-addinguser; 9 &c5-settingenviron; 5 6 <sect1 id="ch05-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>The key to learning what makes a Linux system work is to know 26 what each package is used for and why the user or the system needs it. 27 For this purpose a short summary of the content of each package is given 28 before the actual installation instructions. For a short description of 29 each program in a package, please refer to the corresponding section in 30 <xref linkend="appendixa"/>.</para> 31 32 <para>The build instructions assume that you are using the bash shell. There 33 is also a general expectation that you have already unpacked the sources for a 34 package and have performed a <userinput>cd</userinput> into the unpacked source 35 directory before issuing the build commands.</para> 36 37 <para>Several of the packages are patched before compilation, but only when 38 the patch is needed to circumvent a problem. Often the patch is needed in 39 both this and the next chapter, but sometimes in only one of them. Therefore, 40 don't worry when instructions for a downloaded patch seem to be missing.</para> 41 42 <para>During the installation of most packages you will 43 see all kinds of compiler warnings scroll by on your screen. These are 44 normal and can be safely ignored. They are just what they say they are: 45 warnings -- mostly about deprecated, but not invalid, use of the C or C++ 46 syntax. It's just that C standards have changed rather often and some 47 packages still use the older standard, which is not really a problem.</para> 48 49 <para><emphasis>Unless</emphasis> told not to, you should normally delete the 50 source and build directories after installing each package -- for cleanness 51 sake and to save space.</para> 52 53 <para>Before continuing, make sure the LFS environment variable is set up 54 properly by executing the following:</para> 55 56 <screen><userinput>echo $LFS</userinput></screen> 57 58 <para>Make sure the output shows the path to your LFS partition's mount 59 point, which is <filename class="directory">/mnt/lfs</filename> if you 60 followed our example.</para> 61 62 </sect1> 63 64 65 <sect1 id="ch05-toolchaintechnotes"> 66 <title>Toolchain technical notes</title> 67 <?dbhtml filename="toolchaintechnotes.html" dir="chapter05"?> 68 69 <para>This section attempts to explain some of the rationale and technical 70 details behind the overall build method. It's not essential that you understand 71 everything here immediately. Most of it will make sense once you have performed 72 an actual build. Feel free to refer back here at any time.</para> 73 74 <para>The overall goal of <xref linkend="chapter05"/> is to provide a sane, 75 temporary environment that we can chroot into, and from which we can produce a 76 clean, trouble-free build of the target LFS system in 77 <xref linkend="chapter06"/>. Along the way, we attempt to divorce ourselves 78 from the host system as much as possible, and in so doing build a 79 self-contained and self-hosted toolchain. It should be noted that the 80 build process has been designed in such a way so as to minimize the risks for 81 new readers and provide maximum educational value at the same time. In other 82 words, more advanced techniques could be used to build the system.</para> 83 84 <important> 85 <para>Before continuing, you really should be aware of the name of your working 86 platform, often also referred to as the <emphasis>target triplet</emphasis>. For 87 many folks the target triplet will be, for example: 88 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target 89 triplet is to run the <filename>config.guess</filename> script that comes with 90 the source for many packages. Unpack the Binutils sources and run the script: 91 <userinput>./config.guess</userinput> and note the output.</para> 92 93 <para>You'll also need to be aware of the name of your platform's 94 <emphasis>dynamic linker</emphasis>, often also referred to as the 95 <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker 96 <emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided 97 by Glibc and has the job of finding and loading the shared libraries needed by a 98 program, preparing the program to run and then running it. For most folks, the 99 name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On 100 platforms that are less prevalent, the name might be 101 <emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have 102 something completely different. You should be able to determine the name 103 of your platform's dynamic linker by looking in the 104 <filename class="directory">/lib</filename> directory on your host system. A 105 surefire way is to inspect a random binary from your host system by running: 106 <userinput>'readelf -l <name of binary> | grep interpreter'</userinput> 107 and noting the output. The authoritative reference covering all platforms is in 108 the <filename>shlib-versions</filename> file in the root of the Glibc source 109 tree.</para> 110 </important> 111 112 <para>Some key technical points of how the <xref linkend="chapter05"/> build 113 method works:</para> 114 115 <itemizedlist> 116 <listitem><para>Similar in principle to cross compiling whereby tools installed 117 into the same prefix work in cooperation and thus utilize a little GNU 118 "magic".</para></listitem> 119 120 <listitem><para>Careful manipulation of the standard linker's library search 121 path to ensure programs are linked only against libraries we 122 choose.</para></listitem> 123 124 <listitem><para>Careful manipulation of <userinput>gcc</userinput>'s 125 <emphasis>specs</emphasis> file to tell the compiler which target dynamic 126 linker will be used.</para></listitem> 127 </itemizedlist> 128 129 <para>Binutils is installed first because both GCC and Glibc perform various 130 feature tests on the assembler and linker during their respective runs of 131 <userinput>./configure</userinput> to determine which software features to enable 132 or disable. This is more important than one might first realize. An incorrectly 133 configured GCC or Glibc can result in a subtly broken toolchain where the impact 134 of such breakage might not show up until near the end of the build of a whole 135 distribution. Thankfully, a test suite failure will usually alert us before too 136 much time is wasted.</para> 137 138 <para>Binutils installs its assembler and linker into two locations, 139 <filename class="directory">/tools/bin</filename> and 140 <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality, 141 the tools in one location are hard linked to the other. An important facet of 142 the linker is its library search order. Detailed information can be obtained 143 from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis> 144 flag. For example: <userinput>'ld --verbose | grep SEARCH'</userinput> will 145 show you the current search paths and their order. You can see what files are 146 actually linked by <userinput>ld</userinput> by compiling a dummy program and 147 passing the <emphasis>--verbose</emphasis> switch. For example: 148 <userinput>'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded'</userinput> 149 will show you all the files successfully opened during the link.</para> 150 151 <para>The next package installed is GCC and during its run of 152 <userinput>./configure</userinput> you'll see, for example:</para> 153 154 <blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as 155 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote> 156 157 <para>This is important for the reasons mentioned above. It also demonstrates 158 that GCC's configure script does not search the $PATH directories to find which 159 tools to use. However, during the actual operation of <userinput>gcc</userinput> 160 itself, the same search paths are not necessarily used. You can find out which 161 standard linker <userinput>gcc</userinput> will use by running: 162 <userinput>'gcc -print-prog-name=ld'</userinput>. 163 Detailed information can be obtained from <userinput>gcc</userinput> by passing 164 it the <emphasis>-v</emphasis> flag while compiling a dummy program. For 165 example: <userinput>'gcc -v dummy.c'</userinput> will show you detailed 166 information about the preprocessor, compilation and assembly stages, including 167 <userinput>gcc</userinput>'s include search paths and their order.</para> 168 169 <para>The next package installed is Glibc. The most important considerations for 170 building Glibc are the compiler, binary tools and kernel headers. The compiler 171 is generally no problem as Glibc will always use the <userinput>gcc</userinput> 172 found in a $PATH directory. The binary tools and kernel headers can be a little 173 more troublesome. Therefore we take no risks and use the available configure 174 switches to enforce the correct selections. After the run of 175 <userinput>./configure</userinput> you can check the contents of the 176 <filename>config.make</filename> file in the 177 <filename class="directory">glibc-build</filename> directory for all the 178 important details. You'll note some interesting items like the use of 179 <userinput>CC="gcc -B/tools/bin/"</userinput> to control which binary tools are 180 used, and also the use of the <emphasis>-nostdinc</emphasis> and 181 <emphasis>-isystem</emphasis> flags to control the compiler's include search 182 path. These items help to highlight an important aspect of the Glibc package: 183 it is very self-sufficient in terms of its build machinery and generally does 184 not rely on toolchain defaults.</para> 185 186 <para>After the Glibc installation, we make some adjustments to ensure that 187 searching and linking take place only within our <filename>/tools</filename> 188 prefix. We install an adjusted <userinput>ld</userinput>, which has a hard-wired 189 search path limited to <filename class="directory">/tools/lib</filename>. Then 190 we amend <userinput>gcc</userinput>'s specs file to point to our new dynamic 191 linker in <filename class="directory">/tools/lib</filename>. This last step is 192 <emphasis>vital</emphasis> to the whole process. As mentioned above, a 193 hard-wired path to a dynamic linker is embedded into every ELF shared 194 executable. You can inspect this by running: 195 <userinput>'readelf -l <name of binary> | grep interpreter'</userinput>. 196 By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every 197 program compiled from here through the end of <xref linkend="chapter05"/> will 198 use our new dynamic linker in 199 <filename class="directory">/tools/lib</filename>.</para> 200 201 <para>The need to use the new dynamic linker is also the reason why we apply the 202 Specs patch for the second pass of GCC. Failure to do so will result in the GCC 203 programs themselves having the name of the dynamic linker from the host system's 204 <filename class="directory">/lib</filename> directory embedded into them, which 205 would defeat our goal of getting away from the host.</para> 206 207 <para>During the second pass of Binutils, we are able to utilize the 208 <emphasis>--with-lib-path</emphasis> configure switch to control 209 <userinput>ld</userinput>'s library search path. From this point onwards, the 210 core toolchain is self-contained and self-hosted. The remainder of the 211 <xref linkend="chapter05"/> packages all build against the new Glibc in 212 <filename class="directory">/tools</filename> and all is well.</para> 213 214 <para>Upon entering the chroot environment in <xref linkend="chapter06"/>, the 215 first major package we install is Glibc, due to its self-sufficient nature that 216 we mentioned above. Once this Glibc is installed into 217 <filename class="directory">/usr</filename>, we perform a quick changeover of 218 the toolchain defaults, then proceed for real in building the rest of the 219 target <xref linkend="chapter06"/> LFS system.</para> 220 221 <sect2> 222 <title>Notes on static linking</title> 223 224 <para>Most programs have to perform, beside their specific task, many rather 225 common and sometimes trivial operations. These include allocating memory, 226 searching directories, reading and writing files, string handling, pattern 227 matching, arithmetic and many other tasks. Instead of obliging each program to 228 reinvent the wheel, the GNU system provides all these basic functions in 229 ready-made libraries. The major library on any Linux system is 230 <emphasis>Glibc</emphasis>.</para> 231 232 <para>There are two primary ways of linking the functions from a library to a 233 program that uses them: statically or dynamically. When a program is linked 234 statically, the code of the used functions is included in the executable, 235 resulting in a rather bulky program. When a program is dynamically linked, what 236 is included is a reference to the dynamic linker, the name of the library, and 237 the name of the function, resulting in a much smaller executable. (A third way 238 is to use the programming interface of the dynamic linker. See the 239 <emphasis>dlopen</emphasis> man page for more information.)</para> 240 241 <para>Dynamic linking is the default on Linux and has three major advantages 242 over static linking. First, you need only one copy of the executable library 243 code on your hard disk, instead of having many copies of the same code included 244 into a whole bunch of programs -- thus saving disk space. Second, when several 245 programs use the same library function at the same time, only one copy of the 246 function's code is required in core -- thus saving memory space. Third, when a 247 library function gets a bug fixed or is otherwise improved, you only need to 248 recompile this one library, instead of having to recompile all the programs that 249 make use of the improved function.</para> 250 251 <para>If dynamic linking has several advantages, why then do we statically link 252 the first two packages in this chapter? The reasons are threefold: historical, 253 educational, and technical. Historical, because earlier versions of LFS 254 statically linked every program in this chapter. Educational, because knowing 255 the difference is useful. Technical, because we gain an element of independence 256 from the host in doing so, meaning that those programs can be used 257 independently of the host system. However, it's worth noting that an overall 258 successful LFS build can still be achieved when the first two packages are 259 built dynamically.</para> 260 261 </sect2> 262 263 </sect1> 264 265 266 <sect1 id="ch05-creatingtoolsdir"> 267 <title>Creating the $LFS/tools directory</title> 268 <?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?> 269 270 <para>All programs compiled in this chapter will be installed under <filename 271 class="directory">$LFS/tools</filename> to keep them separate from the 272 programs compiled in the next chapter. The programs compiled here are only 273 temporary tools and won't be a part of the final LFS system and by keeping them 274 in a separate directory, we can later easily throw them away.</para> 275 276 <para>If later you wish to search through the binaries of your system to see 277 what files they make use of or link against, then to make this searching easier 278 you may want to choose a unique name. Instead of the simple "tools" you could 279 use something like "tools-for-lfs".</para> 280 281 <para>Create the required directory by running the following:</para> 282 283 <screen><userinput>mkdir $LFS/tools</userinput></screen> 284 285 <para>The next step is to create a <filename>/tools</filename> symlink on 286 your host system. It will point to the directory we just created on the LFS 287 partition:</para> 288 289 <screen><userinput>ln -s $LFS/tools /</userinput></screen> 290 291 <para>This symlink enables us to compile our toolchain so that it always 292 refers to <filename>/tools</filename>, meaning that the compiler, assembler 293 and linker will work both in this chapter (when we are still using some tools 294 from the host) <emphasis>and</emphasis> in the next (when we are chrooted to 295 the LFS partition).</para> 296 297 <note><para>Study the above command closely. It can be confusing at first 298 glance. The <userinput>ln</userinput> command has several syntax variations, 299 so be sure to check the ln man page before reporting what you may think is an 300 error.</para></note> 301 302 </sect1> 303 304 305 <sect1 id="ch05-addinguser"> 306 <title>Adding the user lfs</title> 307 <?dbhtml filename="addinguser.html" dir="chapter05"?> 308 309 <para>When logged in as <emphasis>root</emphasis>, making a single mistake 310 can damage or even wreck your system. Therefore we recommend that you 311 build the packages in this chapter as an unprivileged user. You could 312 of course use your own user name, but to make it easier to set up a clean 313 work environment we'll create a new user <emphasis>lfs</emphasis> and 314 use this one during the installation process. As <emphasis>root</emphasis>, 315 issue the following commands to add the new user:</para> 316 317 <screen><userinput>useradd -s /bin/bash -m lfs 318 passwd lfs</userinput></screen> 319 320 <para>Now grant this new user <emphasis>lfs</emphasis> full access to 321 <filename class="directory">$LFS/tools</filename> by giving it ownership 322 of the directory:</para> 323 324 <screen><userinput>chown lfs $LFS/tools</userinput></screen> 325 326 <para>If you made a separate working directory as suggested, give user 327 <emphasis>lfs</emphasis> ownership of this directory too:</para> 328 329 <screen><userinput>chown lfs $LFS/sources</userinput></screen> 330 331 <para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a 332 virtual console, through a display manager, or with the following substitute 333 user command:</para> 334 335 <screen><userinput>su - lfs</userinput></screen> 336 337 <para>The "<userinput>-</userinput>" instructs <userinput>su</userinput> to 338 start a new, clean shell.</para> 339 340 </sect1> 341 342 343 <sect1 id="ch05-settingenviron"> 344 <title>Setting up the environment</title> 345 <?dbhtml filename="settingenvironment.html" dir="chapter05"?> 346 347 <para>While logged in as user <emphasis>lfs</emphasis>, issue the 348 following commands to set up a good work environment:</para> 349 350 <screen><userinput>cat > ~/.bash_profile << "EOF"</userinput> 351 set +h 352 umask 022 353 LFS=/mnt/lfs 354 LC_ALL=POSIX 355 PATH=/tools/bin:$PATH 356 export LFS LC_ALL PATH 357 unset CC CXX CPP LD_LIBRARY_PATH LD_PRELOAD 358 <userinput>EOF 359 360 source ~/.bash_profile</userinput></screen> 361 362 <para>The <userinput>set +h</userinput> command turns off 363 <userinput>bash</userinput>'s hash function. Normally hashing is a useful 364 feature: <userinput>bash</userinput> uses a hash table to remember the 365 full pathnames of executable files to avoid searching the PATH time and time 366 again to find the same executable. However, we'd like the new tools to be 367 used as soon as they are installed. By switching off the hash function, our 368 "interactive" commands (<userinput>make</userinput>, 369 <userinput>patch</userinput>, <userinput>sed</userinput>, 370 <userinput>cp</userinput> and so forth) will always use 371 the newest available version during the build process.</para> 372 373 <para>Setting the user file-creation mask to 022 ensures that newly created 374 files and directories are only writable for their owner, but readable and 375 executable for anyone.</para> 376 377 <para>The LFS variable should of course be set to the mount point you 378 chose.</para> 379 380 <para>The LC_ALL variable controls the localization of certain programs, 381 making their messages follow the conventions of a specified country. If your 382 host system uses a version of Glibc older than 2.2.4, 383 having LC_ALL set to something other than "POSIX" or "C" during this chapter 384 may cause trouble if you exit the chroot environment and wish to return later. 385 By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that 386 everything will work as expected in the chroot environment.</para> 387 388 <para>We prepend <filename>/tools/bin</filename> to the standard PATH so 389 that, as we move along through this chapter, the tools we build will get used 390 during the rest of the building process.</para> 391 392 <para>The CC, CXX, CPP, LD_LIBRARY_PATH and LD_PRELOAD environment variables all 393 have the potential to cause havoc with our Chapter 5 toolchain. We therefore 394 unset them to prevent any chance of this happening.</para> 395 396 <para>Now, after sourcing the just-created profile, we're all set to begin 397 building the temporary tools that will support us in later chapters.</para> 398 399 </sect1> 400 401 10 402 &c5-binutils-pass1; 11 403 &c5-gcc-pass1; 12 404 &c5-kernelheaders; 13 405 &c5-glibc; 14 &c5-lockingglibc; 406 407 408 <sect1 id="ch05-locking-glibc"> 409 <title>"Locking in" Glibc</title> 410 <?dbhtml filename="lockingglibc.html" dir="chapter05"?> 411 412 <para>Now that the temporary C libraries have been installed, we want all 413 the tools compiled in the rest of this chapter to be linked against these 414 libraries. To accomplish this, we need to adjust the linker and the compiler's 415 specs file.</para> 416 417 <para>First install the adjusted linker by running the following from within 418 the <filename class="directory">binutils-build</filename> directory:</para> 419 420 <screen><userinput>make -C ld install</userinput></screen> 421 422 <para>The linker was adjusted a little while back, at the end of the first 423 pass of Binutils. From this point onwards everything will link <emphasis>only 424 </emphasis> against the libraries in <filename>/tools/lib</filename>.</para> 425 426 <note><para>If you somehow missed the earlier warning to retain the Binutils 427 source and build directories from the first pass or otherwise accidentally 428 deleted them or just don't have access to them, don't worry, all is not lost. 429 Just ignore the above command. The result is a small chance of subsequent 430 programs linking against libraries on the host. This is not ideal, however, 431 it's not a major problem. The situation is corrected when we install the 432 second pass of Binutils later on.</para></note> 433 434 <para>Now that the adjusted linker is installed, you have to remove the 435 Binutils build and source directories.</para> 436 437 <para>The next thing to do is to amend our GCC specs file so that it points 438 to the new dynamic linker. A simple sed will accomplish this:</para> 439 440 <!-- Ampersands are needed to allow cut and paste --> 441 442 <screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs && 443 sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \ 444 $SPECFILE > tempspecfile && 445 mv -f tempspecfile $SPECFILE && 446 unset SPECFILE</userinput></screen> 447 448 <para>We recommend that you cut-and-paste the above rather than try and type it 449 all in. Or you can edit the specs file by hand if you want to: just replace any 450 occurrence of "/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2".</para> 451 452 <important><para>If you are working on a platform where the name of the dynamic 453 linker is something other than <filename>ld-linux.so.2</filename>, you 454 <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the 455 name of your platform's dynamic linker in the above commands. Refer back to 456 <xref linkend="ch05-toolchaintechnotes"/> if necessary.</para></important> 457 458 <para>Lastly, there is a possibility that some include files from the host 459 system have found their way into GCC's private include dir. This can happen 460 because of GCC's "fixincludes" process which runs as part of the GCC build. 461 We'll explain more about this further on in this chapter. For now, run the 462 following commands to eliminate this possibility:</para> 463 464 <screen><userinput>rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen> 465 466 <!-- HACK - Force some whitespace to appease tidy --> 467 <literallayout></literallayout> 468 469 <caution><para>It is imperative at this point to stop and ensure that the basic 470 functions (compiling and linking) of the new toolchain are working as expected. 471 For this we are going to perform a simple sanity check:</para> 472 473 <screen><userinput>echo 'main(){}' > dummy.c 474 gcc dummy.c 475 readelf -l a.out | grep ': /tools'</userinput></screen> 476 477 <para>If everything is working correctly, there should be no errors, and the 478 output of the last command will be:</para> 479 480 <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote> 481 482 <para>If you did not receive the output as shown above, or received no output at 483 all, then something is seriously wrong. You will need to investigate and retrace 484 your steps to find out where the problem is and correct it. There is no point in 485 continuing until this is done. Most likely something went wrong with the specs 486 file amendment above. Note especially that <filename>/tools/lib</filename> 487 appears as the prefix of our dynamic linker. Of course, if you are working on a 488 platform where the name of the dynamic linker is something other than 489 <filename>ld-linux.so.2</filename>, then the output will be slightly 490 different.</para> 491 492 <para>Once you are satisfied that all is well, clean up the test files:</para> 493 494 <screen><userinput>rm dummy.c a.out</userinput></screen> 495 </caution> 496 497 <!-- HACK - Force some whitespace to appease tidy --> 498 <literallayout></literallayout> 499 500 <para>This completes the installation of the self-contained toolchain, and it 501 can now be used to build the rest of the temporary tools.</para> 502 503 </sect1> 504 505 15 506 &c5-tcl; 16 507 &c5-expect; … … 18 509 &c5-gcc-pass2; 19 510 &c5-binutils-pass2; 511 20 512 &c5-gawk; 21 513 &c5-coreutils;
Note:
See TracChangeset
for help on using the changeset viewer.