[1080241] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
| 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
---|
| 4 | <!ENTITY % general-entities SYSTEM "../../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
| 7 |
|
---|
| 8 | <sect1 id="unpacking">
|
---|
| 9 | <?dbhtml filename="unpacking.html"?>
|
---|
| 10 |
|
---|
| 11 | <sect1info>
|
---|
| 12 | <othername>$LastChangedBy$</othername>
|
---|
| 13 | <date>$Date$</date>
|
---|
| 14 | </sect1info>
|
---|
| 15 |
|
---|
| 16 | <title>Notes on Building Software</title>
|
---|
| 17 |
|
---|
| 18 | <para>Those people who have built an LFS system may be aware
|
---|
| 19 | of the general principles of downloading and unpacking software. We will
|
---|
| 20 | however repeat some of that information here for those new to building
|
---|
| 21 | their own software.</para>
|
---|
| 22 |
|
---|
| 23 | <para>Each set of installation instructions contains a URL from which you
|
---|
| 24 | can download the package. We do however keep a selection of patches
|
---|
| 25 | available via HTTP. These are referenced as needed in the installation
|
---|
| 26 | instructions.</para>
|
---|
| 27 |
|
---|
| 28 | <para>While you can keep the source files anywhere you like, we assume that
|
---|
| 29 | you have unpacked the package and changed into the directory created by the
|
---|
| 30 | unpacking process (the 'build' directory). We also assume you have
|
---|
| 31 | uncompressed any required patches and they are in the directory immediately
|
---|
| 32 | above the 'build' directory.</para>
|
---|
| 33 |
|
---|
| 34 | <para>We can not emphasize strongly enough that you should start from a
|
---|
| 35 | <emphasis>clean source tree</emphasis> each time. This means that if
|
---|
| 36 | you have had an error during configuration or compilation, it's usually
|
---|
| 37 | best to delete the source tree and
|
---|
| 38 | re-unpack it <emphasis>before</emphasis> trying again. This obviously
|
---|
| 39 | doesn't apply if you're an advanced user used to hacking
|
---|
| 40 | <filename>Makefile</filename>s and C code, but if in doubt, start from a
|
---|
| 41 | clean tree.</para>
|
---|
| 42 |
|
---|
| 43 | <sect2>
|
---|
| 44 | <title>Building Software as an Unprivileged (non-root) User</title>
|
---|
| 45 |
|
---|
| 46 | <para>The golden rule of Unix System Administration is to use your
|
---|
| 47 | superpowers only when necessary. Hence, BLFS recommends that you
|
---|
| 48 | build software as an unprivileged user and only become the
|
---|
| 49 | <systemitem class='username'>root</systemitem> user when installing the
|
---|
| 50 | software. This philosophy is followed in all the packages in this book.
|
---|
| 51 | Unless otherwise specified, all instructions should be executed as an
|
---|
| 52 | unprivileged user. The book will advise you on instructions that need
|
---|
| 53 | <systemitem class='username'>root</systemitem> privileges.</para>
|
---|
| 54 |
|
---|
| 55 | </sect2>
|
---|
| 56 |
|
---|
| 57 | <sect2>
|
---|
| 58 | <title>Unpacking the Software</title>
|
---|
| 59 |
|
---|
| 60 | <para>If a file is in <filename class='extension'>.tar</filename> format
|
---|
| 61 | and compressed, it is unpacked by running one of the following
|
---|
| 62 | commands:</para>
|
---|
| 63 |
|
---|
| 64 | <screen><userinput>tar -xvf filename.tar.gz
|
---|
| 65 | tar -xvf filename.tgz
|
---|
| 66 | tar -xvf filename.tar.Z
|
---|
| 67 | tar -xvf filename.tar.bz2</userinput></screen>
|
---|
| 68 |
|
---|
| 69 | <note>
|
---|
| 70 | <para>You may omit using the <option>v</option> parameter in the commands
|
---|
| 71 | shown above and below if you wish to suppress the verbose listing of all
|
---|
| 72 | the files in the archive as they are extracted. This can help speed up the
|
---|
| 73 | extraction as well as make any errors produced during the extraction
|
---|
| 74 | more obvious to you.</para>
|
---|
| 75 | </note>
|
---|
| 76 |
|
---|
| 77 | <para>You can also use a slightly different method:</para>
|
---|
| 78 |
|
---|
| 79 | <screen><userinput>bzcat filename.tar.bz2 | tar -xv</userinput></screen>
|
---|
| 80 |
|
---|
| 81 | <para>Finally, you sometimes need to be able to unpack patches which are
|
---|
| 82 | generally not in <filename class='extension'>.tar</filename> format. The
|
---|
| 83 | best way to do this is to copy the patch file to parent of the 'build'
|
---|
| 84 | directory and then run one of the following commands depending on whether
|
---|
| 85 | the file is a <filename class='extension'>.gz</filename> or <filename
|
---|
| 86 | class='extension'>.bz2</filename> file:</para>
|
---|
| 87 |
|
---|
| 88 | <screen><userinput>gunzip -v patchname.gz
|
---|
| 89 | bunzip2 -v patchname.bz2</userinput></screen>
|
---|
| 90 |
|
---|
| 91 | </sect2>
|
---|
| 92 |
|
---|
| 93 | <sect2>
|
---|
| 94 | <title>Verifying File Integrity Using 'md5sum'</title>
|
---|
| 95 |
|
---|
| 96 | <para>Generally, to verify that the downloaded file is genuine and complete,
|
---|
| 97 | many package maintainers also distribute md5sums of the files. To verify the
|
---|
| 98 | md5sum of the downloaded files, download both the file and the
|
---|
| 99 | corresponding md5sum file to the same directory (preferably from different
|
---|
| 100 | on-line locations), and (assuming <filename>file.md5sum</filename> is the
|
---|
| 101 | md5sum file downloaded) run the following command:</para>
|
---|
| 102 |
|
---|
| 103 | <screen><userinput>md5sum -c file.md5sum</userinput></screen>
|
---|
| 104 |
|
---|
| 105 | <para>If there are any errors, they will be reported. Note that the BLFS
|
---|
| 106 | book includes md5sums for all the source files also. To use the BLFS
|
---|
| 107 | supplied md5sums, you can create a <filename>file.md5sum</filename> (place
|
---|
| 108 | the md5sum data and the exact name of the downloaded file on the same
|
---|
| 109 | line of a file, separated by white space) and run the command shown above.
|
---|
| 110 | Alternately, simply run the command shown below and compare the output
|
---|
| 111 | to the md5sum data shown in the BLFS book.</para>
|
---|
| 112 |
|
---|
| 113 | <screen><userinput>md5sum <replaceable>[name_of_downloaded_file]</replaceable></userinput></screen>
|
---|
| 114 |
|
---|
| 115 | </sect2>
|
---|
| 116 |
|
---|
| 117 | <sect2>
|
---|
| 118 | <title>Creating Log Files During Installation</title>
|
---|
| 119 |
|
---|
| 120 | <para>For larger packages, it is convenient to create log files instead of
|
---|
| 121 | staring at the screen hoping to catch a particular error or warning. Log
|
---|
| 122 | files are also useful for debugging and keeping records. The following
|
---|
| 123 | command allows you to create an installation log. Replace
|
---|
| 124 | <replaceable>[command]</replaceable> with the command you intend to execute.</para>
|
---|
| 125 |
|
---|
| 126 | <screen><userinput>( <replaceable>[command]</replaceable> 2>&1 | tee compile.log && exit $PIPESTATUS )</userinput></screen>
|
---|
| 127 |
|
---|
| 128 | <para><option>2>&1</option> redirects error messages to the same
|
---|
| 129 | location as standard output. The <command>tee</command> command allows
|
---|
| 130 | viewing of the output while logging the results to a file. The parentheses
|
---|
| 131 | around the command run the entire command in a subshell and finally the
|
---|
| 132 | <command>exit $PIPESTATUS</command> command ensures the result of the
|
---|
| 133 | <replaceable>[command]</replaceable> is returned as the result and not the
|
---|
| 134 | result of the <command>tee</command> command.</para>
|
---|
| 135 |
|
---|
| 136 | </sect2>
|
---|
| 137 |
|
---|
| 138 | <sect2 id="automating-builds" xreflabel="Automated Building Procedures">
|
---|
| 139 | <title>Automated Building Procedures</title>
|
---|
| 140 |
|
---|
| 141 | <para>There are times when automating the building of a package can come in
|
---|
| 142 | handy. Everyone has their own reasons for wanting to automate building,
|
---|
| 143 | and everyone goes about it in their own way. Creating
|
---|
| 144 | <filename>Makefile</filename>s, <application>Bash</application> scripts,
|
---|
| 145 | <application>Perl</application> scripts or simply a list of commands used
|
---|
| 146 | to cut and paste are just some of the methods you can use to automate
|
---|
| 147 | building BLFS packages. Detailing how and providing examples of the many
|
---|
| 148 | ways you can automate the building of packages is beyond the scope of this
|
---|
| 149 | section. This section will expose you to using file redirection and the
|
---|
| 150 | <command>yes</command> command to help provide ideas on how to automate
|
---|
| 151 | your builds.</para>
|
---|
| 152 |
|
---|
| 153 | <bridgehead renderas="sect3">File Redirection to Automate Input</bridgehead>
|
---|
| 154 |
|
---|
| 155 | <para>You will find times throughout your BLFS journey when you will come
|
---|
| 156 | across a package that has a command prompting you for information. This
|
---|
| 157 | information might be configuration details, a directory path, or a response
|
---|
| 158 | to a license agreement. This can present a challenge to automate the
|
---|
| 159 | building of that package. Occasionally, you will be prompted for different
|
---|
| 160 | information in a series of questions. One method to automate this type of
|
---|
| 161 | scenario requires putting the desired responses in a file and using
|
---|
| 162 | redirection so that the program uses the data in the file as the answers to
|
---|
| 163 | the questions.</para>
|
---|
| 164 |
|
---|
| 165 | <para>Building the <application>CUPS</application> package is a good
|
---|
| 166 | example of how redirecting a file as input to prompts can help you automate
|
---|
| 167 | the build. If you run the test suite, you are asked to respond to a series
|
---|
| 168 | of questions regarding the type of test to run and if you have any
|
---|
| 169 | auxiliary programs the test can use. You can create a file with your
|
---|
| 170 | responses, one response per line, and use a command similar to the
|
---|
| 171 | one shown below to automate running the test suite:</para>
|
---|
| 172 |
|
---|
| 173 | <screen><userinput>make check < ../cups-1.1.23-testsuite_parms</userinput></screen>
|
---|
| 174 |
|
---|
| 175 | <para>This effectively makes the test suite use the responses in the file
|
---|
| 176 | as the input to the questions. Impressive, don't you think? Occasionally
|
---|
| 177 | you may end up doing a bit of trial and error determining the exact format
|
---|
| 178 | of your input file for some things, but once figured out and documented you
|
---|
| 179 | can use this to automate building the package.</para>
|
---|
| 180 |
|
---|
| 181 | <bridgehead renderas="sect3">Using <command>yes</command> to Automate
|
---|
| 182 | Input</bridgehead>
|
---|
| 183 |
|
---|
| 184 | <para>Sometimes you will only need to provide one response, or provide the
|
---|
| 185 | same response to many prompts. For these instances, the
|
---|
| 186 | <command>yes</command> command works really well. The
|
---|
| 187 | <command>yes</command> command can be used to provide a response (the same
|
---|
| 188 | one) to one or more instances of questions. It can be used to simulate
|
---|
| 189 | pressing just the <keycap>Enter</keycap> key, entering the
|
---|
| 190 | <keycap>Y</keycap> key or entering a string of text. Perhaps the easiest
|
---|
| 191 | way to show its use is in an example.</para>
|
---|
| 192 |
|
---|
| 193 | <para>First, create a short <application>Bash</application> script by
|
---|
| 194 | entering the following commands:</para>
|
---|
| 195 |
|
---|
| 196 | <screen><userinput>cat > blfsyestest1 << "EOF"
|
---|
| 197 | <literal>#!/bin/bash
|
---|
| 198 |
|
---|
| 199 | echo -n -e \\n\\n"Please type something (or nothing) and press Enter ---> "
|
---|
| 200 |
|
---|
| 201 | read A_STRING
|
---|
| 202 |
|
---|
| 203 | if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed"
|
---|
| 204 | else A_STRING="You entered '$A_STRING'"
|
---|
| 205 | fi
|
---|
| 206 |
|
---|
| 207 | echo -e \\n\\n$A_STRING\\n\\n</literal>
|
---|
| 208 | EOF
|
---|
| 209 | chmod 755 blfsyestest1</userinput></screen>
|
---|
| 210 |
|
---|
| 211 | <para>Now run the script by issuing <command>./blfsyestest1</command> from
|
---|
| 212 | the command line. It will wait for a response, which can be anything (or
|
---|
| 213 | nothing) followed by the <keycap>Enter</keycap> key. After entering
|
---|
| 214 | something, the result will be echoed to the screen. Now use the
|
---|
| 215 | <command>yes</command> command to automate the entering of a
|
---|
| 216 | response:</para>
|
---|
| 217 |
|
---|
| 218 | <screen><userinput>yes | ./blfsyestest1</userinput></screen>
|
---|
| 219 |
|
---|
| 220 | <para>Notice that piping <command>yes</command> by itself to the script
|
---|
| 221 | results in <keycap>y</keycap> being passed to the script. Now try it with a
|
---|
| 222 | string of text:</para>
|
---|
| 223 |
|
---|
| 224 | <screen><userinput>yes 'This is some text' | ./blfsyestest1</userinput></screen>
|
---|
| 225 |
|
---|
| 226 | <para>The exact string was used as the response to the script. Finally,
|
---|
| 227 | try it using an empty (null) string:</para>
|
---|
| 228 |
|
---|
| 229 | <screen><userinput>yes '' | ./blfsyestest1</userinput></screen>
|
---|
| 230 |
|
---|
| 231 | <para>Notice this results in passing just the press of the
|
---|
| 232 | <keycap>Enter</keycap> key to the script. This is useful for times when the
|
---|
| 233 | default answer to the prompt is sufficient. This syntax is used in the
|
---|
| 234 | <xref linkend="net-tools-automate-example"/> instructions to accept all the
|
---|
| 235 | defaults to the many prompts during the configuration step. You may now
|
---|
| 236 | remove the test script, if desired.</para>
|
---|
| 237 |
|
---|
| 238 | <bridgehead renderas="sect3">File Redirection to Automate Output</bridgehead>
|
---|
| 239 |
|
---|
| 240 | <para>In order to automate the building of some packages, especially those
|
---|
| 241 | that require you to read a license agreement one page at a time, requires
|
---|
| 242 | using a method that avoids having to press a key to display each page.
|
---|
| 243 | Redirecting the output to a file can be used in these instances to assist
|
---|
| 244 | with the automation. The previous section on this page touched on creating
|
---|
| 245 | log files of the build output. The redirection method shown there used the
|
---|
| 246 | <command>tee</command> command to redirect output to a file while also
|
---|
| 247 | displaying the output to the screen. Here, the output will only be sent to
|
---|
| 248 | a file.</para>
|
---|
| 249 |
|
---|
| 250 | <para>Again, the easiest way to demonstrate the technique is to show an
|
---|
| 251 | example. First, issue the command:</para>
|
---|
| 252 |
|
---|
| 253 | <screen><userinput>ls -l /usr/bin | more</userinput></screen>
|
---|
| 254 |
|
---|
| 255 | <para>Of course, you'll be required to view the output one page at a time
|
---|
| 256 | because the <command>more</command> filter was used. Now try the same
|
---|
| 257 | command, but this time redirect the output to a file. The special file
|
---|
| 258 | <filename>/dev/null</filename> can be used instead of the filename shown,
|
---|
| 259 | but you will have no log file to examine:</para>
|
---|
| 260 |
|
---|
| 261 | <screen><userinput>ls -l /usr/bin | more > redirect_test.log 2>&1</userinput></screen>
|
---|
| 262 |
|
---|
| 263 | <para>Notice that this time the command immediately returned to the shell
|
---|
| 264 | prompt without having to page through the output. The last example will use
|
---|
| 265 | the <command>yes</command> command in combination with output redirection
|
---|
| 266 | to bypass having to page through the output and then providing a
|
---|
| 267 | <keycap>y</keycap> to a prompt. This technique could be used in instances
|
---|
| 268 | where otherwise you would have to page through the output of a file (such
|
---|
| 269 | as a license agreement) and then answer the question of <quote>do you
|
---|
| 270 | accept the above?</quote>. For this example, another short
|
---|
| 271 | <application>Bash</application> script is required:</para>
|
---|
| 272 |
|
---|
| 273 | <screen><userinput>cat > blfsyestest2 << "EOF"
|
---|
| 274 | <literal>#!/bin/bash
|
---|
| 275 |
|
---|
| 276 | ls -l /usr/bin | more
|
---|
| 277 |
|
---|
| 278 | echo -n -e \\n\\n"Did you enjoy reading this? (y,n) "
|
---|
| 279 |
|
---|
| 280 | read A_STRING
|
---|
| 281 |
|
---|
| 282 | if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key"
|
---|
| 283 | else A_STRING="You did NOT enter the 'y' key"
|
---|
| 284 | fi
|
---|
| 285 |
|
---|
| 286 | echo -e \\n\\n$A_STRING\\n\\n</literal>
|
---|
| 287 | EOF
|
---|
| 288 | chmod 755 blfsyestest2</userinput></screen>
|
---|
| 289 |
|
---|
| 290 | <para>This script can be used to simulate a program that requires you to
|
---|
| 291 | read a license agreement, then respond appropriately to accept the
|
---|
| 292 | agreement before the program will install anything. First, run the script
|
---|
| 293 | without any automation techniques by issuing
|
---|
| 294 | <command>./blfsyestest2</command>.</para>
|
---|
| 295 |
|
---|
| 296 | <para>Now issue the following command which uses two automation techniques,
|
---|
| 297 | making it suitable for use in an automated build script:</para>
|
---|
| 298 |
|
---|
| 299 | <screen><userinput>yes | ./blfsyestest2 > blfsyestest2.log 2>&1</userinput></screen>
|
---|
| 300 |
|
---|
| 301 | <para>If desired, issue <command>tail blfsyestest2.log</command> to see
|
---|
| 302 | the end of the paged output, and confirmation that <keycap>y</keycap> was
|
---|
| 303 | passed through to the script. Once satisfied that it works as it should,
|
---|
| 304 | you may remove the script and log file.</para>
|
---|
| 305 |
|
---|
| 306 | <para>Finally, keep in mind that there are many ways to automate and/or
|
---|
| 307 | script the build commands. There is not a single <quote>correct</quote> way
|
---|
| 308 | to do it. Your imagination is the only limit.</para>
|
---|
| 309 |
|
---|
| 310 | </sect2>
|
---|
| 311 |
|
---|
| 312 | <sect2>
|
---|
| 313 | <title>Dependencies</title>
|
---|
| 314 |
|
---|
| 315 | <para>For each package described, BLFS lists the known dependencies.
|
---|
| 316 | These are listed under several headings, whose meaning is as follows:</para>
|
---|
| 317 |
|
---|
| 318 | <itemizedlist>
|
---|
| 319 | <listitem>
|
---|
| 320 | <para><emphasis>Required</emphasis> means that the target package
|
---|
| 321 | cannot be correctly built without the dependency having first been
|
---|
| 322 | installed.</para>
|
---|
| 323 | </listitem>
|
---|
| 324 | <listitem>
|
---|
| 325 | <para><emphasis>Recommended</emphasis> means that BLFS strongly
|
---|
| 326 | suggests this package is installed first for a clean and trouble-free
|
---|
| 327 | build, that won't have issues either during the build process, or at
|
---|
| 328 | run-time.</para>
|
---|
| 329 | </listitem>
|
---|
| 330 | <listitem>
|
---|
| 331 | <para><emphasis>Optional</emphasis> means that this package might be
|
---|
| 332 | installed for added functionality. Often BLFS will describe the
|
---|
| 333 | dependency to explain the added functionality that will result.</para>
|
---|
| 334 | </listitem>
|
---|
| 335 | </itemizedlist>
|
---|
| 336 |
|
---|
| 337 | </sect2>
|
---|
| 338 |
|
---|
| 339 | </sect1>
|
---|