[1080241] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
[6732c094] | 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
---|
[1080241] | 4 | <!ENTITY % general-entities SYSTEM "../../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
| 7 |
|
---|
| 8 | <sect1 id="unpacking">
|
---|
[82c65b7] | 9 | <?dbhtml filename="notes-on-building.html"?>
|
---|
[1080241] | 10 |
|
---|
| 11 | <sect1info>
|
---|
| 12 | <date>$Date$</date>
|
---|
| 13 | </sect1info>
|
---|
| 14 |
|
---|
| 15 | <title>Notes on Building Software</title>
|
---|
| 16 |
|
---|
| 17 | <para>Those people who have built an LFS system may be aware
|
---|
[ec64d28] | 18 | of the general principles of downloading and unpacking software. Some
|
---|
| 19 | of that information is repeated here for those new to building
|
---|
[1080241] | 20 | their own software.</para>
|
---|
| 21 |
|
---|
| 22 | <para>Each set of installation instructions contains a URL from which you
|
---|
[ec64d28] | 23 | can download the package. The patches; however, are stored on the LFS
|
---|
| 24 | servers and are available via HTTP. These are referenced as needed in the
|
---|
| 25 | installation instructions.</para>
|
---|
[1080241] | 26 |
|
---|
| 27 | <para>While you can keep the source files anywhere you like, we assume that
|
---|
| 28 | you have unpacked the package and changed into the directory created by the
|
---|
| 29 | unpacking process (the 'build' directory). We also assume you have
|
---|
| 30 | uncompressed any required patches and they are in the directory immediately
|
---|
| 31 | above the 'build' directory.</para>
|
---|
| 32 |
|
---|
| 33 | <para>We can not emphasize strongly enough that you should start from a
|
---|
| 34 | <emphasis>clean source tree</emphasis> each time. This means that if
|
---|
| 35 | you have had an error during configuration or compilation, it's usually
|
---|
| 36 | best to delete the source tree and
|
---|
| 37 | re-unpack it <emphasis>before</emphasis> trying again. This obviously
|
---|
| 38 | doesn't apply if you're an advanced user used to hacking
|
---|
| 39 | <filename>Makefile</filename>s and C code, but if in doubt, start from a
|
---|
| 40 | clean tree.</para>
|
---|
| 41 |
|
---|
| 42 | <sect2>
|
---|
| 43 | <title>Building Software as an Unprivileged (non-root) User</title>
|
---|
| 44 |
|
---|
| 45 | <para>The golden rule of Unix System Administration is to use your
|
---|
| 46 | superpowers only when necessary. Hence, BLFS recommends that you
|
---|
| 47 | build software as an unprivileged user and only become the
|
---|
| 48 | <systemitem class='username'>root</systemitem> user when installing the
|
---|
| 49 | software. This philosophy is followed in all the packages in this book.
|
---|
| 50 | Unless otherwise specified, all instructions should be executed as an
|
---|
| 51 | unprivileged user. The book will advise you on instructions that need
|
---|
| 52 | <systemitem class='username'>root</systemitem> privileges.</para>
|
---|
| 53 |
|
---|
| 54 | </sect2>
|
---|
| 55 |
|
---|
| 56 | <sect2>
|
---|
| 57 | <title>Unpacking the Software</title>
|
---|
| 58 |
|
---|
| 59 | <para>If a file is in <filename class='extension'>.tar</filename> format
|
---|
| 60 | and compressed, it is unpacked by running one of the following
|
---|
| 61 | commands:</para>
|
---|
| 62 |
|
---|
| 63 | <screen><userinput>tar -xvf filename.tar.gz
|
---|
| 64 | tar -xvf filename.tgz
|
---|
| 65 | tar -xvf filename.tar.Z
|
---|
| 66 | tar -xvf filename.tar.bz2</userinput></screen>
|
---|
| 67 |
|
---|
| 68 | <note>
|
---|
| 69 | <para>You may omit using the <option>v</option> parameter in the commands
|
---|
| 70 | shown above and below if you wish to suppress the verbose listing of all
|
---|
| 71 | the files in the archive as they are extracted. This can help speed up the
|
---|
| 72 | extraction as well as make any errors produced during the extraction
|
---|
| 73 | more obvious to you.</para>
|
---|
| 74 | </note>
|
---|
| 75 |
|
---|
| 76 | <para>You can also use a slightly different method:</para>
|
---|
| 77 |
|
---|
| 78 | <screen><userinput>bzcat filename.tar.bz2 | tar -xv</userinput></screen>
|
---|
| 79 |
|
---|
| 80 | <para>Finally, you sometimes need to be able to unpack patches which are
|
---|
| 81 | generally not in <filename class='extension'>.tar</filename> format. The
|
---|
[4d3e5f1] | 82 | best way to do this is to copy the patch file to the parent of the 'build'
|
---|
[1080241] | 83 | directory and then run one of the following commands depending on whether
|
---|
| 84 | the file is a <filename class='extension'>.gz</filename> or <filename
|
---|
| 85 | class='extension'>.bz2</filename> file:</para>
|
---|
| 86 |
|
---|
| 87 | <screen><userinput>gunzip -v patchname.gz
|
---|
| 88 | bunzip2 -v patchname.bz2</userinput></screen>
|
---|
| 89 |
|
---|
| 90 | </sect2>
|
---|
| 91 |
|
---|
| 92 | <sect2>
|
---|
[6333296] | 93 | <title>Verifying File Integrity</title>
|
---|
[1080241] | 94 |
|
---|
[6333296] | 95 | <para>Generally, to verify that the downloaded file is complete,
|
---|
[1080241] | 96 | many package maintainers also distribute md5sums of the files. To verify the
|
---|
| 97 | md5sum of the downloaded files, download both the file and the
|
---|
| 98 | corresponding md5sum file to the same directory (preferably from different
|
---|
| 99 | on-line locations), and (assuming <filename>file.md5sum</filename> is the
|
---|
| 100 | md5sum file downloaded) run the following command:</para>
|
---|
| 101 |
|
---|
| 102 | <screen><userinput>md5sum -c file.md5sum</userinput></screen>
|
---|
| 103 |
|
---|
| 104 | <para>If there are any errors, they will be reported. Note that the BLFS
|
---|
| 105 | book includes md5sums for all the source files also. To use the BLFS
|
---|
| 106 | supplied md5sums, you can create a <filename>file.md5sum</filename> (place
|
---|
| 107 | the md5sum data and the exact name of the downloaded file on the same
|
---|
| 108 | line of a file, separated by white space) and run the command shown above.
|
---|
| 109 | Alternately, simply run the command shown below and compare the output
|
---|
| 110 | to the md5sum data shown in the BLFS book.</para>
|
---|
| 111 |
|
---|
[57b11363] | 112 | <screen><userinput>md5sum <replaceable><name_of_downloaded_file></replaceable></userinput></screen>
|
---|
[1080241] | 113 |
|
---|
[6333296] | 114 | <para>MD5 is not cryptographically secure, so the md5sums are only
|
---|
[97ba425] | 115 | provided for detecting unmalicious changes to the file content. For
|
---|
| 116 | example, an error or truncation introduced during network transfer, or
|
---|
| 117 | a <quote>stealth</quote> update to the package from the upstream
|
---|
| 118 | (updating the content of a released tarball instead of making a new
|
---|
| 119 | release properly).</para>
|
---|
| 120 |
|
---|
| 121 | <para>There is no <quote>100%</quote> secure way to make
|
---|
[6333296] | 122 | sure the genuity of the source files. Assuming the upstream is managing
|
---|
| 123 | their website correctly (the private key is not leaked and the domain is
|
---|
| 124 | not hijacked), and the trust anchors have been set up correctly using
|
---|
| 125 | <xref linkend="make-ca"/> on the BLFS system, we can reasonably trust
|
---|
| 126 | download URLs to the upstream official website
|
---|
| 127 | <emphasis role="bold">with https protocol</emphasis>. Note that
|
---|
| 128 | BLFS book itself is published on a website with https, so you should
|
---|
| 129 | already have some confidence in https protocol or you wouldn't trust the
|
---|
| 130 | book content.</para>
|
---|
| 131 |
|
---|
| 132 | <para>If the package is downloaded from an unofficial location (for
|
---|
| 133 | example a local mirror), checksums generated by cryptographically secure
|
---|
| 134 | digest algorithms (for example SHA256) can be used to verify the
|
---|
| 135 | genuity of the package. Download the checksum file from the upstream
|
---|
| 136 | <emphasis role="bold">official</emphasis> website (or somewhere
|
---|
| 137 | <emphasis role="bold">you can trust</emphasis>) and compare the
|
---|
| 138 | checksum of the package from unoffical location with it. For example,
|
---|
| 139 | SHA256 checksum can be checked with the command:</para>
|
---|
| 140 |
|
---|
| 141 | <note>
|
---|
| 142 | <para>If the checksum and the package are downloaded from the same
|
---|
| 143 | untrusted location, you won't gain security enhancement by verifying
|
---|
| 144 | the package with the checksum. The attacker can fake the checksum as
|
---|
| 145 | well as compromising the package itself.</para>
|
---|
| 146 | </note>
|
---|
| 147 |
|
---|
| 148 | <screen><userinput>sha256sum -c <replaceable>file</replaceable>.sha256sum</userinput></screen>
|
---|
| 149 |
|
---|
| 150 | <para>If <xref linkend="gnupg2"/> is installed, you can also verify the
|
---|
| 151 | genuity of the package with a GPG signature. Import the upstream GPG
|
---|
| 152 | public key with:</para>
|
---|
| 153 |
|
---|
| 154 | <screen><userinput>gpg --recv-key <replaceable>keyID</replaceable></userinput></screen>
|
---|
| 155 |
|
---|
| 156 | <para><replaceable>keyID</replaceable> should be replaced with the key ID
|
---|
| 157 | from somewhere <emphasis role="bold">you can trust</emphasis> (for
|
---|
| 158 | example, copy it from the upstream official website using https). Now
|
---|
| 159 | you can verify the signature with:</para>
|
---|
| 160 |
|
---|
| 161 | <screen><userinput>gpg --recv-key <replaceable>file</replaceable>.sig <replaceable>file</replaceable></userinput></screen>
|
---|
| 162 |
|
---|
| 163 | <para>The advantage of <application>GnuPG</application> signature is,
|
---|
| 164 | once you imported a public key which can be trusted, you can download
|
---|
| 165 | both the package and its signature from the same unofficial location and
|
---|
| 166 | verify them with the public key. So you won't need to connect to the
|
---|
| 167 | official upstream website to retrieve a checksum for each new release.
|
---|
| 168 | You only need to update the public key if it's expired or revoked.
|
---|
| 169 | </para>
|
---|
| 170 |
|
---|
[1080241] | 171 | </sect2>
|
---|
| 172 |
|
---|
| 173 | <sect2>
|
---|
| 174 | <title>Creating Log Files During Installation</title>
|
---|
| 175 |
|
---|
| 176 | <para>For larger packages, it is convenient to create log files instead of
|
---|
| 177 | staring at the screen hoping to catch a particular error or warning. Log
|
---|
| 178 | files are also useful for debugging and keeping records. The following
|
---|
| 179 | command allows you to create an installation log. Replace
|
---|
[57b11363] | 180 | <replaceable><command></replaceable> with the command you intend to execute.</para>
|
---|
[1080241] | 181 |
|
---|
[57b11363] | 182 | <screen><userinput>( <replaceable><command></replaceable> 2>&1 | tee compile.log && exit $PIPESTATUS )</userinput></screen>
|
---|
[1080241] | 183 |
|
---|
| 184 | <para><option>2>&1</option> redirects error messages to the same
|
---|
| 185 | location as standard output. The <command>tee</command> command allows
|
---|
| 186 | viewing of the output while logging the results to a file. The parentheses
|
---|
| 187 | around the command run the entire command in a subshell and finally the
|
---|
| 188 | <command>exit $PIPESTATUS</command> command ensures the result of the
|
---|
[57b11363] | 189 | <replaceable><command></replaceable> is returned as the result and not the
|
---|
[1080241] | 190 | result of the <command>tee</command> command.</para>
|
---|
| 191 |
|
---|
| 192 | </sect2>
|
---|
| 193 |
|
---|
[82c65b7] | 194 | <sect2 id="parallel-builds" xreflabel="Using Multiple Processors">
|
---|
| 195 | <title>Using Multiple Processors</title>
|
---|
| 196 |
|
---|
| 197 | <para>For many modern systems with multiple processors (or cores) the
|
---|
| 198 | compilation time for a package can be reduced by performing a "parallel
|
---|
| 199 | make" by either setting an environment variable or telling the make program
|
---|
| 200 | how many processors are available. For instance, a Core2Duo can support two
|
---|
| 201 | simultaneous processes with: </para>
|
---|
| 202 |
|
---|
| 203 | <screen><userinput>export MAKEFLAGS='-j2'</userinput></screen>
|
---|
| 204 |
|
---|
| 205 | <para>or just building with:</para>
|
---|
| 206 |
|
---|
| 207 | <screen><userinput>make -j2</userinput></screen>
|
---|
| 208 |
|
---|
| 209 | <para>Generally the number of processes should not exceed the number of
|
---|
| 210 | cores supported by the CPU. To list the processors on your
|
---|
| 211 | system, issue: <userinput>grep processor /proc/cpuinfo</userinput>.
|
---|
| 212 | </para>
|
---|
| 213 |
|
---|
| 214 | <para>In some cases, using multiple processors may result in a 'race'
|
---|
| 215 | condition where the success of the build depends on the order of the
|
---|
| 216 | commands run by the <command>make</command> program. For instance, if an
|
---|
[ea20da9] | 217 | executable needs File A and File B, attempting to link the program before
|
---|
[82c65b7] | 218 | one of the dependent components is available will result in a failure.
|
---|
| 219 | This condition usually arises because the upstream developer has not
|
---|
[30203c2c] | 220 | properly designated all the prerequisites needed to accomplish a step in the
|
---|
[82c65b7] | 221 | Makefile.</para>
|
---|
| 222 |
|
---|
| 223 | <para>If this occurs, the best way to proceed is to drop back to a
|
---|
| 224 | single processor build. Adding '-j1' to a make command will override
|
---|
| 225 | the similar setting in the MAKEFLAGS environment variable.</para>
|
---|
| 226 |
|
---|
[e58667e] | 227 | <note><para>When running the package tests or the install portion of the
|
---|
| 228 | package build process, we do not recommend using an option greater than
|
---|
| 229 | '-j1' unless specified otherwise. The installation procedures or checks
|
---|
| 230 | have not been validated using parallel procedures and may fail with issues
|
---|
| 231 | that are difficult to debug.</para></note>
|
---|
| 232 |
|
---|
[82c65b7] | 233 | </sect2>
|
---|
| 234 |
|
---|
[1080241] | 235 | <sect2 id="automating-builds" xreflabel="Automated Building Procedures">
|
---|
| 236 | <title>Automated Building Procedures</title>
|
---|
| 237 |
|
---|
| 238 | <para>There are times when automating the building of a package can come in
|
---|
| 239 | handy. Everyone has their own reasons for wanting to automate building,
|
---|
| 240 | and everyone goes about it in their own way. Creating
|
---|
| 241 | <filename>Makefile</filename>s, <application>Bash</application> scripts,
|
---|
| 242 | <application>Perl</application> scripts or simply a list of commands used
|
---|
| 243 | to cut and paste are just some of the methods you can use to automate
|
---|
| 244 | building BLFS packages. Detailing how and providing examples of the many
|
---|
| 245 | ways you can automate the building of packages is beyond the scope of this
|
---|
| 246 | section. This section will expose you to using file redirection and the
|
---|
| 247 | <command>yes</command> command to help provide ideas on how to automate
|
---|
| 248 | your builds.</para>
|
---|
| 249 |
|
---|
| 250 | <bridgehead renderas="sect3">File Redirection to Automate Input</bridgehead>
|
---|
| 251 |
|
---|
| 252 | <para>You will find times throughout your BLFS journey when you will come
|
---|
| 253 | across a package that has a command prompting you for information. This
|
---|
| 254 | information might be configuration details, a directory path, or a response
|
---|
| 255 | to a license agreement. This can present a challenge to automate the
|
---|
| 256 | building of that package. Occasionally, you will be prompted for different
|
---|
| 257 | information in a series of questions. One method to automate this type of
|
---|
| 258 | scenario requires putting the desired responses in a file and using
|
---|
| 259 | redirection so that the program uses the data in the file as the answers to
|
---|
| 260 | the questions.</para>
|
---|
| 261 |
|
---|
| 262 | <para>Building the <application>CUPS</application> package is a good
|
---|
| 263 | example of how redirecting a file as input to prompts can help you automate
|
---|
| 264 | the build. If you run the test suite, you are asked to respond to a series
|
---|
| 265 | of questions regarding the type of test to run and if you have any
|
---|
| 266 | auxiliary programs the test can use. You can create a file with your
|
---|
| 267 | responses, one response per line, and use a command similar to the
|
---|
| 268 | one shown below to automate running the test suite:</para>
|
---|
| 269 |
|
---|
| 270 | <screen><userinput>make check < ../cups-1.1.23-testsuite_parms</userinput></screen>
|
---|
| 271 |
|
---|
| 272 | <para>This effectively makes the test suite use the responses in the file
|
---|
[4677cbc] | 273 | as the input to the questions. Occasionally you may end up doing a bit of
|
---|
| 274 | trial and error determining the exact format of your input file for some
|
---|
| 275 | things, but once figured out and documented you can use this to automate
|
---|
| 276 | building the package.</para>
|
---|
[1080241] | 277 |
|
---|
| 278 | <bridgehead renderas="sect3">Using <command>yes</command> to Automate
|
---|
| 279 | Input</bridgehead>
|
---|
| 280 |
|
---|
| 281 | <para>Sometimes you will only need to provide one response, or provide the
|
---|
| 282 | same response to many prompts. For these instances, the
|
---|
| 283 | <command>yes</command> command works really well. The
|
---|
| 284 | <command>yes</command> command can be used to provide a response (the same
|
---|
| 285 | one) to one or more instances of questions. It can be used to simulate
|
---|
| 286 | pressing just the <keycap>Enter</keycap> key, entering the
|
---|
| 287 | <keycap>Y</keycap> key or entering a string of text. Perhaps the easiest
|
---|
| 288 | way to show its use is in an example.</para>
|
---|
| 289 |
|
---|
| 290 | <para>First, create a short <application>Bash</application> script by
|
---|
| 291 | entering the following commands:</para>
|
---|
| 292 |
|
---|
[4677cbc] | 293 | <screen><userinput>cat > blfs-yes-test1 << "EOF"
|
---|
[1080241] | 294 | <literal>#!/bin/bash
|
---|
| 295 |
|
---|
[4677cbc] | 296 | echo -n -e "\n\nPlease type something (or nothing) and press Enter ---> "
|
---|
[1080241] | 297 |
|
---|
| 298 | read A_STRING
|
---|
| 299 |
|
---|
| 300 | if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed"
|
---|
| 301 | else A_STRING="You entered '$A_STRING'"
|
---|
| 302 | fi
|
---|
| 303 |
|
---|
[4677cbc] | 304 | echo -e "\n\n$A_STRING\n\n"</literal>
|
---|
[1080241] | 305 | EOF
|
---|
[4677cbc] | 306 | chmod 755 blfs-yes-test1</userinput></screen>
|
---|
[1080241] | 307 |
|
---|
[4677cbc] | 308 | <para>Now run the script by issuing <command>./blfs-yes-test1</command> from
|
---|
[1080241] | 309 | the command line. It will wait for a response, which can be anything (or
|
---|
| 310 | nothing) followed by the <keycap>Enter</keycap> key. After entering
|
---|
| 311 | something, the result will be echoed to the screen. Now use the
|
---|
| 312 | <command>yes</command> command to automate the entering of a
|
---|
| 313 | response:</para>
|
---|
| 314 |
|
---|
[4677cbc] | 315 | <screen><userinput>yes | ./blfs-yes-test1</userinput></screen>
|
---|
[1080241] | 316 |
|
---|
| 317 | <para>Notice that piping <command>yes</command> by itself to the script
|
---|
| 318 | results in <keycap>y</keycap> being passed to the script. Now try it with a
|
---|
| 319 | string of text:</para>
|
---|
| 320 |
|
---|
[4677cbc] | 321 | <screen><userinput>yes 'This is some text' | ./blfs-yes-test1</userinput></screen>
|
---|
[1080241] | 322 |
|
---|
| 323 | <para>The exact string was used as the response to the script. Finally,
|
---|
| 324 | try it using an empty (null) string:</para>
|
---|
| 325 |
|
---|
[4677cbc] | 326 | <screen><userinput>yes '' | ./blfs-yes-test1</userinput></screen>
|
---|
[1080241] | 327 |
|
---|
| 328 | <para>Notice this results in passing just the press of the
|
---|
| 329 | <keycap>Enter</keycap> key to the script. This is useful for times when the
|
---|
| 330 | default answer to the prompt is sufficient. This syntax is used in the
|
---|
| 331 | <xref linkend="net-tools-automate-example"/> instructions to accept all the
|
---|
| 332 | defaults to the many prompts during the configuration step. You may now
|
---|
| 333 | remove the test script, if desired.</para>
|
---|
| 334 |
|
---|
| 335 | <bridgehead renderas="sect3">File Redirection to Automate Output</bridgehead>
|
---|
| 336 |
|
---|
| 337 | <para>In order to automate the building of some packages, especially those
|
---|
| 338 | that require you to read a license agreement one page at a time, requires
|
---|
[6473e74] | 339 | using a method that avoids having to press a key to display each page.
|
---|
[1080241] | 340 | Redirecting the output to a file can be used in these instances to assist
|
---|
| 341 | with the automation. The previous section on this page touched on creating
|
---|
| 342 | log files of the build output. The redirection method shown there used the
|
---|
| 343 | <command>tee</command> command to redirect output to a file while also
|
---|
| 344 | displaying the output to the screen. Here, the output will only be sent to
|
---|
| 345 | a file.</para>
|
---|
| 346 |
|
---|
| 347 | <para>Again, the easiest way to demonstrate the technique is to show an
|
---|
| 348 | example. First, issue the command:</para>
|
---|
| 349 |
|
---|
| 350 | <screen><userinput>ls -l /usr/bin | more</userinput></screen>
|
---|
| 351 |
|
---|
| 352 | <para>Of course, you'll be required to view the output one page at a time
|
---|
| 353 | because the <command>more</command> filter was used. Now try the same
|
---|
| 354 | command, but this time redirect the output to a file. The special file
|
---|
| 355 | <filename>/dev/null</filename> can be used instead of the filename shown,
|
---|
| 356 | but you will have no log file to examine:</para>
|
---|
| 357 |
|
---|
| 358 | <screen><userinput>ls -l /usr/bin | more > redirect_test.log 2>&1</userinput></screen>
|
---|
| 359 |
|
---|
| 360 | <para>Notice that this time the command immediately returned to the shell
|
---|
[4677cbc] | 361 | prompt without having to page through the output. You may now remove the
|
---|
| 362 | log file.</para>
|
---|
| 363 |
|
---|
| 364 | <para>The last example will use the <command>yes</command> command in
|
---|
| 365 | combination with output redirection to bypass having to page through the
|
---|
| 366 | output and then provide a <keycap>y</keycap> to a prompt. This technique
|
---|
| 367 | could be used in instances when otherwise you would have to page through
|
---|
| 368 | the output of a file (such as a license agreement) and then answer the
|
---|
| 369 | question of <quote>do you accept the above?</quote>. For this example,
|
---|
| 370 | another short <application>Bash</application> script is required:</para>
|
---|
| 371 |
|
---|
| 372 | <screen><userinput>cat > blfs-yes-test2 << "EOF"
|
---|
[1080241] | 373 | <literal>#!/bin/bash
|
---|
| 374 |
|
---|
| 375 | ls -l /usr/bin | more
|
---|
| 376 |
|
---|
[4677cbc] | 377 | echo -n -e "\n\nDid you enjoy reading this? (y,n) "
|
---|
[1080241] | 378 |
|
---|
| 379 | read A_STRING
|
---|
| 380 |
|
---|
| 381 | if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key"
|
---|
| 382 | else A_STRING="You did NOT enter the 'y' key"
|
---|
| 383 | fi
|
---|
| 384 |
|
---|
[4677cbc] | 385 | echo -e "\n\n$A_STRING\n\n"</literal>
|
---|
[1080241] | 386 | EOF
|
---|
[4677cbc] | 387 | chmod 755 blfs-yes-test2</userinput></screen>
|
---|
[1080241] | 388 |
|
---|
| 389 | <para>This script can be used to simulate a program that requires you to
|
---|
| 390 | read a license agreement, then respond appropriately to accept the
|
---|
| 391 | agreement before the program will install anything. First, run the script
|
---|
| 392 | without any automation techniques by issuing
|
---|
[4677cbc] | 393 | <command>./blfs-yes-test2</command>.</para>
|
---|
[1080241] | 394 |
|
---|
| 395 | <para>Now issue the following command which uses two automation techniques,
|
---|
| 396 | making it suitable for use in an automated build script:</para>
|
---|
| 397 |
|
---|
[4677cbc] | 398 | <screen><userinput>yes | ./blfs-yes-test2 > blfs-yes-test2.log 2>&1</userinput></screen>
|
---|
[1080241] | 399 |
|
---|
[4677cbc] | 400 | <para>If desired, issue <command>tail blfs-yes-test2.log</command> to see
|
---|
[1080241] | 401 | the end of the paged output, and confirmation that <keycap>y</keycap> was
|
---|
| 402 | passed through to the script. Once satisfied that it works as it should,
|
---|
| 403 | you may remove the script and log file.</para>
|
---|
| 404 |
|
---|
| 405 | <para>Finally, keep in mind that there are many ways to automate and/or
|
---|
| 406 | script the build commands. There is not a single <quote>correct</quote> way
|
---|
| 407 | to do it. Your imagination is the only limit.</para>
|
---|
| 408 |
|
---|
| 409 | </sect2>
|
---|
| 410 |
|
---|
| 411 | <sect2>
|
---|
| 412 | <title>Dependencies</title>
|
---|
| 413 |
|
---|
| 414 | <para>For each package described, BLFS lists the known dependencies.
|
---|
| 415 | These are listed under several headings, whose meaning is as follows:</para>
|
---|
| 416 |
|
---|
| 417 | <itemizedlist>
|
---|
| 418 | <listitem>
|
---|
| 419 | <para><emphasis>Required</emphasis> means that the target package
|
---|
| 420 | cannot be correctly built without the dependency having first been
|
---|
| 421 | installed.</para>
|
---|
| 422 | </listitem>
|
---|
| 423 | <listitem>
|
---|
| 424 | <para><emphasis>Recommended</emphasis> means that BLFS strongly
|
---|
| 425 | suggests this package is installed first for a clean and trouble-free
|
---|
| 426 | build, that won't have issues either during the build process, or at
|
---|
[c7c1722] | 427 | run-time. The instructions in the book assume these packages are
|
---|
| 428 | installed. Some changes or workarounds may be required if these
|
---|
| 429 | packages are not installed.</para>
|
---|
[1080241] | 430 | </listitem>
|
---|
| 431 | <listitem>
|
---|
| 432 | <para><emphasis>Optional</emphasis> means that this package might be
|
---|
| 433 | installed for added functionality. Often BLFS will describe the
|
---|
| 434 | dependency to explain the added functionality that will result.</para>
|
---|
| 435 | </listitem>
|
---|
| 436 | </itemizedlist>
|
---|
| 437 |
|
---|
| 438 | </sect2>
|
---|
| 439 |
|
---|
[5d28d0d4] | 440 | <sect2 id="package_updates">
|
---|
| 441 | <title>Using the Most Current Package Sources</title>
|
---|
| 442 |
|
---|
| 443 | <para>On occasion you may run into a situation in the book when a package
|
---|
| 444 | will not build or work properly. Though the Editors attempt to ensure
|
---|
| 445 | that every package in the book builds and works properly, sometimes a
|
---|
| 446 | package has been overlooked or was not tested with this particular version
|
---|
| 447 | of BLFS.</para>
|
---|
| 448 |
|
---|
| 449 | <para>If you discover that a package will not build or work properly, you
|
---|
| 450 | should see if there is a more current version of the package. Typically
|
---|
| 451 | this means you go to the maintainer's web site and download the most current
|
---|
| 452 | tarball and attempt to build the package. If you cannot determine the
|
---|
| 453 | maintainer's web site by looking at the download URLs, use Google and query
|
---|
| 454 | the package's name. For example, in the Google search bar type:
|
---|
| 455 | 'package_name download' (omit the quotes) or something similar. Sometimes
|
---|
| 456 | typing: 'package_name home page' will result in you finding the
|
---|
| 457 | maintainer's web site.</para>
|
---|
| 458 |
|
---|
| 459 | </sect2>
|
---|
| 460 |
|
---|
[3c31062] | 461 | <sect2 id="stripping">
|
---|
| 462 | <title>Stripping One More Time</title>
|
---|
| 463 |
|
---|
[dddebae7] | 464 | <warning>
|
---|
| 465 | <para>If you did not strip programs and libraries in LFS,
|
---|
| 466 | the following will probably make your system unusable. To avoid that,
|
---|
[8558044] | 467 | run the instructions at <ulink url="&lfs-root;/chapter08/strippingagain.html"/>
|
---|
| 468 | instead. After the critical files are stripped using those instructions,
|
---|
[dddebae7] | 469 | the instructions below can be run any time new packages are installed.
|
---|
| 470 | </para>
|
---|
| 471 | </warning>
|
---|
| 472 |
|
---|
[aade25df] | 473 | <para>
|
---|
| 474 | In LFS, stripping of debugging symbols was discussed a couple of
|
---|
| 475 | times. When building BLFS packages, there are generally no special
|
---|
| 476 | instructions that discuss stripping again. It is probably not a good
|
---|
| 477 | idea to strip an executable or a library while it is in use, so exiting
|
---|
| 478 | any windowing environment is a good idea. Then you can do:
|
---|
| 479 | </para>
|
---|
[3c31062] | 480 |
|
---|
[7a3422b1] | 481 | <screen><userinput>find /usr/{bin,lib,sbin} \
|
---|
[1c3f6da1] | 482 | -type f \( -name \*.so* -a ! -name \*dbg \) \
|
---|
| 483 | -exec strip --strip-unneeded {} \;</userinput></screen>
|
---|
[f3429309] | 484 |
|
---|
[aade25df] | 485 | <para>
|
---|
| 486 | If you install programs in other directories such as <filename
|
---|
| 487 | class="directory">/opt</filename> or <filename
|
---|
| 488 | class="directory">/usr/local</filename>, you may want to strip the files
|
---|
| 489 | there too.
|
---|
| 490 | </para>
|
---|
[3c31062] | 491 |
|
---|
[aade25df] | 492 | <para>
|
---|
| 493 | For more information on stripping, see <ulink
|
---|
| 494 | url="http://www.technovelty.org/linux/stripping-shared-libraries.html"/>.
|
---|
| 495 | </para>
|
---|
[3c31062] | 496 |
|
---|
| 497 | </sect2>
|
---|
[6f3460d2] | 498 | <!--
|
---|
[3c31062] | 499 | <sect2 id="libtool">
|
---|
| 500 | <title>Libtool files</title>
|
---|
| 501 |
|
---|
[aade25df] | 502 | <para>
|
---|
| 503 | One of the side effects of packages that use Autotools, including
|
---|
| 504 | libtool, is that they create many files with an .la extension. These
|
---|
| 505 | files are not needed in an LFS environment. If there are conflicts with
|
---|
| 506 | pkgconfig entries, they can actually prevent successful builds. You
|
---|
| 507 | may want to consider removing these files periodically:
|
---|
| 508 | </para>
|
---|
[3c31062] | 509 |
|
---|
[ba7bf15c] | 510 | <screen><userinput>find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete</userinput></screen>
|
---|
[16d0ef21] | 511 |
|
---|
[aade25df] | 512 | <para>
|
---|
| 513 | The above command removes all .la files with the exception of those that
|
---|
| 514 | have <quote>Image</quote> or <quote>openldap</quote> as a part of the
|
---|
| 515 | path. These .la files are used by the ImageMagick and openldap programs,
|
---|
| 516 | respectively. There may be other exceptions by packages not in BLFS.
|
---|
| 517 | </para>
|
---|
[16d0ef21] | 518 |
|
---|
[3c31062] | 519 | </sect2>
|
---|
[6f3460d2] | 520 | -->
|
---|
[ab8c10c8] | 521 | <sect2 id="buildsystems">
|
---|
| 522 | <title>Working with different build systems</title>
|
---|
| 523 |
|
---|
| 524 | <para>
|
---|
| 525 | There are now three different build systems in common use for
|
---|
| 526 | converting C or C++ source code into compiled programs or
|
---|
[367853f] | 527 | libraries and their details (particularly, finding out about available
|
---|
[ab8c10c8] | 528 | options and their default values) differ. It may be easiest to understand
|
---|
[367853f] | 529 | the issues caused by some choices (typically slow execution or
|
---|
[8fd509cb] | 530 | unexpected use of, or omission of, optimizatons) by starting with
|
---|
| 531 | the CFLAGS and CXXFLAGS environment variables. There are also some
|
---|
| 532 | programs which use rust.
|
---|
[ab8c10c8] | 533 | </para>
|
---|
| 534 |
|
---|
| 535 | <para>
|
---|
| 536 | Most LFS and BLFS builders are probably aware of the basics of CFLAGS
|
---|
| 537 | and CXXFLAGS for altering how a program is compiled. Typically, some
|
---|
[367853f] | 538 | form of optimization is used by upstream developers (-O2 or -O3),
|
---|
| 539 | sometimes with the creation of debug symbols (-g), as defaults.
|
---|
[ab8c10c8] | 540 | </para>
|
---|
| 541 |
|
---|
| 542 | <para>
|
---|
| 543 | If there are contradictory flags (e.g. multiple different -O values),
|
---|
| 544 | the <emphasis>last</emphasis> value will be used. Sometimes this means
|
---|
[367853f] | 545 | that flags specified in environment variables will be picked up before
|
---|
[ab8c10c8] | 546 | values hardcoded in the Makefile, and therefore ignored. For example,
|
---|
| 547 | where a user specifies '-O2' and that is followed by '-O3' the build will
|
---|
| 548 | use '-O3'.
|
---|
| 549 | </para>
|
---|
| 550 |
|
---|
| 551 | <para>
|
---|
| 552 | There are various other things which can be passed in CFLAGS or
|
---|
| 553 | CXXFLAGS, such as forcing compilation for a specific microarchitecture
|
---|
| 554 | (e.g. -march=amdfam10, -march=native) or specifying a specific standard
|
---|
| 555 | for C or C++ (-std=c++17 for example). But one thing which has now come
|
---|
| 556 | to light is that programmers might include debug assertions in their
|
---|
| 557 | code, expecting them to be disabled in releases by using -DNDEBUG.
|
---|
| 558 | Specifically, if <xref linkend="mesa"/> is built with these assertions
|
---|
| 559 | enabled, some activities such as loading levels of games can take
|
---|
| 560 | extremely long times, even on high-class video cards.
|
---|
| 561 | </para>
|
---|
| 562 |
|
---|
[367853f] | 563 | <bridgehead renderas="sect3" id="autotools-info">Autotools with Make</bridgehead>
|
---|
[ab8c10c8] | 564 |
|
---|
| 565 | <para>
|
---|
| 566 | This combination is often described as 'CMMI' (configure, make, make
|
---|
| 567 | install) and is used here to also cover the few packages which have a
|
---|
| 568 | configure script that is not generated by autotools.
|
---|
| 569 | </para>
|
---|
| 570 |
|
---|
| 571 | <para>
|
---|
[367853f] | 572 | Sometimes running <command>./configure --help</command> will produce
|
---|
[ab8c10c8] | 573 | useful options about switches which might be used. At other times,
|
---|
[367853f] | 574 | after looking at the output from configure you may need to look
|
---|
[ab8c10c8] | 575 | at the details of the script to find out what it was actually searching
|
---|
| 576 | for.
|
---|
| 577 | </para>
|
---|
| 578 |
|
---|
| 579 | <para>
|
---|
| 580 | Many configure scripts will pick up any CFLAGS or CXXFLAGS from the
|
---|
| 581 | environment, but CMMI packages vary about how these will be mixed with
|
---|
| 582 | any flags which would otherwise be used (<emphasis>variously</emphasis>:
|
---|
| 583 | ignored, used to replace the programmer's suggestion, used before the
|
---|
[367853f] | 584 | programmer's suggestion, or used after the programmer's suggestion).
|
---|
[ab8c10c8] | 585 | </para>
|
---|
| 586 |
|
---|
| 587 | <para>
|
---|
| 588 | In most CMMI packages, running 'make' will list each command and run
|
---|
| 589 | it, interspersed with any warnings. But some packages try to be 'silent'
|
---|
| 590 | and only show which file they are compiling or linking instead of showing
|
---|
| 591 | the command line. If you need to inspect the command, either because of
|
---|
| 592 | an error, or just to see what options and flags are being used, adding
|
---|
| 593 | 'V=1' to the make invocation may help.
|
---|
| 594 | </para>
|
---|
| 595 |
|
---|
[367853f] | 596 | <bridgehead renderas="sect3" id="cmake-info">CMake</bridgehead>
|
---|
[ab8c10c8] | 597 |
|
---|
| 598 | <para>
|
---|
| 599 | CMake works in a very different way, and it has two backends which can
|
---|
| 600 | be used on BLFS: 'make' and 'ninja'. The default backend is make, but
|
---|
| 601 | ninja can be faster on large packages with multiple processors. To
|
---|
[c0e4599e] | 602 | use ninja, specify '-G Ninja' in the cmake command. However, there are
|
---|
| 603 | some packages which create fatal errors in their ninja files but build
|
---|
| 604 | successfully using the default of Unix Makefiles.
|
---|
[ab8c10c8] | 605 | </para>
|
---|
| 606 |
|
---|
| 607 | <para>
|
---|
| 608 | The hardest part of using CMake is knowing what options you might wish
|
---|
| 609 | to specify. The only way to get a list of what the package knows about
|
---|
| 610 | is to run <command>cmake -LAH</command> and look at the output for that
|
---|
| 611 | default configuration.
|
---|
| 612 | </para>
|
---|
| 613 |
|
---|
| 614 | <para>
|
---|
| 615 | Perhaps the most-important thing about CMake is that it has a variety
|
---|
| 616 | of CMAKE_BUILD_TYPE values, and these affect the flags. The default
|
---|
| 617 | is that this is not set and no flags are generated. Any CFLAGS or
|
---|
[367853f] | 618 | CXXFLAGS in the environment will be used. If the programmer has coded
|
---|
[ab8c10c8] | 619 | any debug assertions, those will be enabled unless -DNDEBUG is used.
|
---|
| 620 | The following CMAKE_BUILD_TYPE values will generate the flags shown,
|
---|
| 621 | and these will come <emphasis>after</emphasis> any flags in the
|
---|
| 622 | environment and therefore take precedence.
|
---|
| 623 | </para>
|
---|
| 624 |
|
---|
| 625 | <itemizedlist>
|
---|
| 626 | <listitem>
|
---|
| 627 | <para>Debug : '-g'</para>
|
---|
| 628 | </listitem>
|
---|
| 629 | <listitem>
|
---|
| 630 | <para>Release : '-O3 -DNDEBUG'</para>
|
---|
| 631 | </listitem>
|
---|
| 632 | <listitem>
|
---|
| 633 | <para>RelWithDebInfo : '-O2 -g -DNDEBUG'</para>
|
---|
| 634 | </listitem>
|
---|
| 635 | <listitem>
|
---|
| 636 | <para>MinSizeRel : '-Os -DNDEBUG'</para>
|
---|
| 637 | </listitem>
|
---|
| 638 | </itemizedlist>
|
---|
| 639 |
|
---|
| 640 | <para>
|
---|
| 641 | CMake tries to produce quiet builds. To see the details of the commands
|
---|
| 642 | which are being run, use 'make VERBOSE=1' or 'ninja -v'.
|
---|
| 643 | </para>
|
---|
| 644 |
|
---|
[367853f] | 645 | <bridgehead renderas="sect3" id="meson-info">Meson</bridgehead>
|
---|
[ab8c10c8] | 646 |
|
---|
| 647 | <para>
|
---|
| 648 | Meson has some similarities to CMake, but many differences. To get
|
---|
[f66b2ee] | 649 | details of the defines that you may wish to change you can look at
|
---|
| 650 | <filename>meson_options.txt</filename> which is usually in the
|
---|
| 651 | top-level directory.
|
---|
[ab8c10c8] | 652 | </para>
|
---|
| 653 |
|
---|
| 654 | <para>
|
---|
[f66b2ee] | 655 | If you have already configured the package by running
|
---|
| 656 | <command>meson</command> and now wish to change one or more settings,
|
---|
| 657 | you can either remove the build directory, recreate it, and use the
|
---|
| 658 | altered options, or within the build directory run <command>meson
|
---|
| 659 | configure</command>, e.g. to set an option:
|
---|
[ab8c10c8] | 660 | </para>
|
---|
| 661 |
|
---|
[f66b2ee] | 662 | <screen><userinput>meson configure -D<some_option>=true</userinput></screen>
|
---|
[ab8c10c8] | 663 |
|
---|
| 664 | <para>
|
---|
[f66b2ee] | 665 | If you do that, the file <filename>meson-private/cmd_line.txt</filename>
|
---|
| 666 | will show the <emphasis>last</emphasis> commands which were used.
|
---|
[ab8c10c8] | 667 | </para>
|
---|
| 668 |
|
---|
| 669 | <para>
|
---|
| 670 | Meson provides the following buildtype values, and the flags they enable
|
---|
| 671 | come <emphasis>after</emphasis> any flags supplied in the environment and
|
---|
| 672 | therefore take precedence.
|
---|
| 673 | </para>
|
---|
| 674 |
|
---|
| 675 | <itemizedlist>
|
---|
| 676 | <listitem>
|
---|
| 677 | <para>plain : no added flags. This is for distributors to supply their
|
---|
| 678 | own CLFAGS, CXXFLAGS and LDFLAGS. There is no obvious reason to use
|
---|
| 679 | this in BLFS.</para>
|
---|
| 680 | </listitem>
|
---|
| 681 | <listitem>
|
---|
[65877d86] | 682 | <para>debug : '-g' - this is the default if nothing is specified
|
---|
[8554ad2] | 683 | in either <filename>meson.build</filename> or the command line.
|
---|
[c98fc5b] | 684 | However it results large and slow binaries, so we should override
|
---|
| 685 | it in BLFS.</para>
|
---|
[ab8c10c8] | 686 | </listitem>
|
---|
| 687 | <listitem>
|
---|
[65877d86] | 688 | <para>debugoptimized : '-O2 -g' : this is the default specified in
|
---|
| 689 | <filename>meson.build</filename> of some packages.</para>
|
---|
[ab8c10c8] | 690 | </listitem>
|
---|
| 691 | <listitem>
|
---|
[8fd509cb] | 692 | <para>release : '-O3 -DNDEBUG' (but occasionally a package will force
|
---|
| 693 | -O2 here)</para>
|
---|
[ab8c10c8] | 694 | </listitem>
|
---|
| 695 | </itemizedlist>
|
---|
| 696 |
|
---|
| 697 | <para>
|
---|
[367853f] | 698 | Although the 'release' buildtype is described as enabling -DNDEBUG, and all
|
---|
[ab8c10c8] | 699 | CMake Release builds pass that, it has so far only been observed (in
|
---|
| 700 | verbose builds) for <xref linkend="mesa"/>. That suggests that it might
|
---|
| 701 | only be used when there are debug assertions present.
|
---|
| 702 | </para>
|
---|
| 703 |
|
---|
| 704 | <para>
|
---|
| 705 | The -DNDEBUG flag can also be provided by passing
|
---|
| 706 | <command>-Db_ndebug=true</command>.
|
---|
| 707 | </para>
|
---|
| 708 |
|
---|
| 709 | <para>
|
---|
| 710 | To see the details of the commands which are being run in a package using
|
---|
[367853f] | 711 | meson, use 'ninja -v'.
|
---|
[ab8c10c8] | 712 | </para>
|
---|
| 713 |
|
---|
[8fd509cb] | 714 | <bridgehead renderas="sect3" id="rust-info">Rustc and Cargo</bridgehead>
|
---|
| 715 |
|
---|
| 716 | <para>
|
---|
| 717 | Most released rustc programs are provided as crates (source tarballs)
|
---|
| 718 | which will query a server to check current versions of dependencies
|
---|
| 719 | and then download them as necessary. These packages are built using
|
---|
| 720 | <command>cargo --release</command>. In theory, you can manipulate the
|
---|
| 721 | RUSTFLAGS to change the optimize-level (default is 3, like -O3, e.g.
|
---|
| 722 | <literal>-Copt-level=3</literal>) or to force it to build for the
|
---|
| 723 | machine it is being compiled on, using
|
---|
| 724 | <literal>-Ctarget-cpu=native</literal> but in practice this seems to
|
---|
| 725 | make no significant difference.
|
---|
| 726 | </para>
|
---|
| 727 |
|
---|
| 728 | <para>
|
---|
| 729 | If you find an interesting rustc program which is only provided as
|
---|
| 730 | unpackaged source, you should at least specify
|
---|
| 731 | <literal>RUSTFLAGS=-Copt-level=2</literal> otherwise it will do an
|
---|
| 732 | unoptimized compile with debug info and run <emphasis>much</emphasis>
|
---|
| 733 | slower.
|
---|
| 734 | </para>
|
---|
| 735 |
|
---|
[5ce1bdb] | 736 | <para>
|
---|
| 737 | The rust developers seem to assume that everyone will compile on a
|
---|
| 738 | machine dedicated to producing builds, so by default all CPUs are used.
|
---|
| 739 | This can often be worked around, either by exporting
|
---|
| 740 | CARGO_BUILD_JOBS=<N> or passing --jobs <N> to cargo. For
|
---|
| 741 | compiling rustc itself, specifying --jobs <N> on invocations of
|
---|
| 742 | x.py (together with the <envar>CARGO_BUILD_JOBS</envar> environment
|
---|
| 743 | variable, which looks like a "belt and braces" approach but seems to be
|
---|
| 744 | necessary) mostly works. The exception is running the tests when building
|
---|
| 745 | rustc, some of them will nevertheless use all online CPUs, at least as of
|
---|
| 746 | rustc-1.42.0.
|
---|
| 747 | </para>
|
---|
| 748 |
|
---|
[8fd509cb] | 749 | </sect2>
|
---|
| 750 |
|
---|
| 751 | <sect2 id="optimizations">
|
---|
| 752 | <title>Optimizing the build</title>
|
---|
| 753 |
|
---|
| 754 | <para>
|
---|
| 755 | Many people will prefer to optimize compiles as they see fit, by providing
|
---|
| 756 | CFLAGS or CXXFLAGS. For an introduction to the options available with gcc
|
---|
| 757 | and g++ see <ulink
|
---|
| 758 | url="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html"/> and <ulink
|
---|
| 759 | url="https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html"/>
|
---|
| 760 | and <command>info gcc</command>.
|
---|
| 761 |
|
---|
| 762 | </para>
|
---|
| 763 |
|
---|
| 764 | <para>
|
---|
| 765 | Some packages default to '-O2 -g', others to '-O3 -g', and if CFLAGS or
|
---|
| 766 | CXXFLAGS are supplied they might be added to the package's defaults,
|
---|
| 767 | replace the package's defaults, or even be ignored. There are details
|
---|
| 768 | on some desktop packages which were mostly current in April 2019 at
|
---|
[c9aa980] | 769 | <ulink url="https://www.linuxfromscratch.org/~ken/tuning/"/> - in
|
---|
[8fd509cb] | 770 | particular, README.txt, tuning-1-packages-and-notes.txt, and
|
---|
| 771 | tuning-notes-2B.txt. The particular thing to remember is that if you
|
---|
[7c93be03] | 772 | want to try some of the more interesting flags you may need to force
|
---|
[8fd509cb] | 773 | verbose builds to confirm what is being used.
|
---|
| 774 | </para>
|
---|
| 775 |
|
---|
| 776 | <para>
|
---|
| 777 | Clearly, if you are optimizing your own program you can spend time to
|
---|
| 778 | profile it and perhaps recode some of it if it is too slow. But for
|
---|
| 779 | building a whole system that approach is impractical. In general,
|
---|
| 780 | -O3 usually produces faster programs than -O2. Specifying
|
---|
| 781 | -march=native is also beneficial, but means that you cannot move the
|
---|
| 782 | binaries to an incompatible machine - this can also apply to newer
|
---|
| 783 | machines, not just to older machines. For example programs compiled for
|
---|
| 784 | 'amdfam10' run on old Phenoms, Kaveris, and Ryzens : but programs
|
---|
| 785 | compiled for a Kaveri will not run on a Ryzen because certain op-codes
|
---|
| 786 | are not present. Similarly, if you build for a Haswell not everything
|
---|
| 787 | will run on a SandyBridge.
|
---|
| 788 | </para>
|
---|
| 789 |
|
---|
| 790 | <para>
|
---|
| 791 | There are also various other options which some people claim are
|
---|
| 792 | beneficial. At worst, you get to recompile and test, and then
|
---|
| 793 | discover that in your usage the options do not provide a benefit.
|
---|
| 794 | </para>
|
---|
| 795 |
|
---|
| 796 | <para>
|
---|
| 797 | If building Perl or Python modules, or Qt packages which use qmake,
|
---|
| 798 | in general the CFLAGS and CXXFLAGS used are those which were used by
|
---|
| 799 | those 'parent' packages.
|
---|
| 800 | </para>
|
---|
| 801 |
|
---|
| 802 | </sect2>
|
---|
| 803 |
|
---|
| 804 | <sect2 id="hardening">
|
---|
| 805 | <title>Options for hardening the build</title>
|
---|
| 806 |
|
---|
| 807 | <para>
|
---|
| 808 | Even on desktop systems, there are still a lot of exploitable
|
---|
| 809 | vulnerabilities. For many of these, the attack comes via javascript
|
---|
[52249aa] | 810 | in a browser. Often, a series of vulnerabilities are used to gain
|
---|
[8fd509cb] | 811 | access to data (or sometimes to pwn, i.e. own, the machine and
|
---|
| 812 | install rootkits). Most commercial distros will apply various
|
---|
| 813 | hardening measures.
|
---|
| 814 | </para>
|
---|
| 815 |
|
---|
| 816 | <para>
|
---|
| 817 | For hardening options which are reasonably cheap, there is some
|
---|
| 818 | discussion in the 'tuning' link above (occasionally, one or more
|
---|
| 819 | of these options might be inappropriate for a package). These
|
---|
| 820 | options are -D_FORTIFY_SOURCE=2, -fstack-protector=strong, and
|
---|
| 821 | (for C++) -D_GLIBCXX_ASSERTIONS. On modern machines these should
|
---|
| 822 | only have a little impact on how fast things run, and often they
|
---|
| 823 | will not be noticeable.
|
---|
| 824 | </para>
|
---|
| 825 |
|
---|
| 826 | <para>
|
---|
| 827 | In the past, there was Hardened LFS where gcc (a much older version)
|
---|
| 828 | was forced to use hardening (with options to turn some of it off on a
|
---|
| 829 | per-package basis. What is being covered here is different - first you
|
---|
| 830 | have to make sure that the package is indeed using your added flags and
|
---|
| 831 | not over-riding them.
|
---|
| 832 | </para>
|
---|
| 833 |
|
---|
| 834 | <para>
|
---|
| 835 | The main distros use much more, such as RELRO (Relocation Read Only)
|
---|
| 836 | and perhaps -fstack-clash-protection. You may also encounter the
|
---|
| 837 | so-called 'userspace retpoline' (-mindirect-branch=thunk etc.) which
|
---|
| 838 | is the equivalent of the spectre mitigations applied to the linux
|
---|
[7c93be03] | 839 | kernel in late 2018). The kernel mitigations caused a lot of complaints
|
---|
[8fd509cb] | 840 | about lost performance, if you have a production server you might wish
|
---|
| 841 | to consider testing that, along with the other available options, to
|
---|
| 842 | see if performance is still sufficient.
|
---|
| 843 | </para>
|
---|
| 844 |
|
---|
| 845 | <para>
|
---|
| 846 | Whilst gcc has many hardening options, clang/LLVM's strengths lie
|
---|
| 847 | elsewhere. Some options which gcc provides are said to be less effective
|
---|
[bf5fb94] | 848 | in clang/LLVM.
|
---|
[8fd509cb] | 849 | </para>
|
---|
| 850 |
|
---|
[ab8c10c8] | 851 | </sect2>
|
---|
| 852 |
|
---|
[1080241] | 853 | </sect1>
|
---|