source: introduction/important/building-notes.xml@ c0e4599e

10.0 10.1 11.0 9.1 ken/refactor-virt lazarus qt5new trunk xry111/git-date xry111/git-date-for-trunk xry111/git-date-test
Last change on this file since c0e4599e was c0e4599e, checked in by Ken Moffat <ken@…>, 20 months ago

Build systems - remark that there are some cmake packages (not necessarily in BLFS)
which produce bad ninja.build files but usable Makefiles.

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@22751 af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 34.0 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % general-entities SYSTEM "../../general.ent">
5 %general-entities;
6]>
7
8<sect1 id="unpacking">
9 <?dbhtml filename="notes-on-building.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. Some
20 of that information is repeated 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. The patches; however, are stored on the LFS
25 servers and are available via HTTP. These are referenced as needed in the
26 installation 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
65tar -xvf filename.tgz
66tar -xvf filename.tar.Z
67tar -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 the 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
89bunzip2 -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>&lt;name_of_downloaded_file&gt;</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>&lt;command&gt;</replaceable> with the command you intend to execute.</para>
125
126<screen><userinput>( <replaceable>&lt;command&gt;</replaceable> 2&gt;&amp;1 | tee compile.log &amp;&amp; exit $PIPESTATUS )</userinput></screen>
127
128 <para><option>2&gt;&amp;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>&lt;command&gt;</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="parallel-builds" xreflabel="Using Multiple Processors">
139 <title>Using Multiple Processors</title>
140
141 <para>For many modern systems with multiple processors (or cores) the
142 compilation time for a package can be reduced by performing a "parallel
143 make" by either setting an environment variable or telling the make program
144 how many processors are available. For instance, a Core2Duo can support two
145 simultaneous processes with: </para>
146
147 <screen><userinput>export MAKEFLAGS='-j2'</userinput></screen>
148
149 <para>or just building with:</para>
150
151 <screen><userinput>make -j2</userinput></screen>
152
153 <para>Generally the number of processes should not exceed the number of
154 cores supported by the CPU. To list the processors on your
155 system, issue: <userinput>grep processor /proc/cpuinfo</userinput>.
156 </para>
157
158 <para>In some cases, using multiple processors may result in a 'race'
159 condition where the success of the build depends on the order of the
160 commands run by the <command>make</command> program. For instance, if an
161 executable needs File A and File B, attempting to link the program before
162 one of the dependent components is available will result in a failure.
163 This condition usually arises because the upstream developer has not
164 properly designated all the prerequisites needed to accomplish a step in the
165 Makefile.</para>
166
167 <para>If this occurs, the best way to proceed is to drop back to a
168 single processor build. Adding '-j1' to a make command will override
169 the similar setting in the MAKEFLAGS environment variable.</para>
170
171 <note><para>When running the package tests or the install portion of the
172 package build process, we do not recommend using an option greater than
173 '-j1' unless specified otherwise. The installation procedures or checks
174 have not been validated using parallel procedures and may fail with issues
175 that are difficult to debug.</para></note>
176
177 </sect2>
178
179 <sect2 id="automating-builds" xreflabel="Automated Building Procedures">
180 <title>Automated Building Procedures</title>
181
182 <para>There are times when automating the building of a package can come in
183 handy. Everyone has their own reasons for wanting to automate building,
184 and everyone goes about it in their own way. Creating
185 <filename>Makefile</filename>s, <application>Bash</application> scripts,
186 <application>Perl</application> scripts or simply a list of commands used
187 to cut and paste are just some of the methods you can use to automate
188 building BLFS packages. Detailing how and providing examples of the many
189 ways you can automate the building of packages is beyond the scope of this
190 section. This section will expose you to using file redirection and the
191 <command>yes</command> command to help provide ideas on how to automate
192 your builds.</para>
193
194 <bridgehead renderas="sect3">File Redirection to Automate Input</bridgehead>
195
196 <para>You will find times throughout your BLFS journey when you will come
197 across a package that has a command prompting you for information. This
198 information might be configuration details, a directory path, or a response
199 to a license agreement. This can present a challenge to automate the
200 building of that package. Occasionally, you will be prompted for different
201 information in a series of questions. One method to automate this type of
202 scenario requires putting the desired responses in a file and using
203 redirection so that the program uses the data in the file as the answers to
204 the questions.</para>
205
206 <para>Building the <application>CUPS</application> package is a good
207 example of how redirecting a file as input to prompts can help you automate
208 the build. If you run the test suite, you are asked to respond to a series
209 of questions regarding the type of test to run and if you have any
210 auxiliary programs the test can use. You can create a file with your
211 responses, one response per line, and use a command similar to the
212 one shown below to automate running the test suite:</para>
213
214<screen><userinput>make check &lt; ../cups-1.1.23-testsuite_parms</userinput></screen>
215
216 <para>This effectively makes the test suite use the responses in the file
217 as the input to the questions. Occasionally you may end up doing a bit of
218 trial and error determining the exact format of your input file for some
219 things, but once figured out and documented you can use this to automate
220 building the package.</para>
221
222 <bridgehead renderas="sect3">Using <command>yes</command> to Automate
223 Input</bridgehead>
224
225 <para>Sometimes you will only need to provide one response, or provide the
226 same response to many prompts. For these instances, the
227 <command>yes</command> command works really well. The
228 <command>yes</command> command can be used to provide a response (the same
229 one) to one or more instances of questions. It can be used to simulate
230 pressing just the <keycap>Enter</keycap> key, entering the
231 <keycap>Y</keycap> key or entering a string of text. Perhaps the easiest
232 way to show its use is in an example.</para>
233
234 <para>First, create a short <application>Bash</application> script by
235 entering the following commands:</para>
236
237<screen><userinput>cat &gt; blfs-yes-test1 &lt;&lt; "EOF"
238<literal>#!/bin/bash
239
240echo -n -e "\n\nPlease type something (or nothing) and press Enter ---> "
241
242read A_STRING
243
244if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed"
245else A_STRING="You entered '$A_STRING'"
246fi
247
248echo -e "\n\n$A_STRING\n\n"</literal>
249EOF
250chmod 755 blfs-yes-test1</userinput></screen>
251
252 <para>Now run the script by issuing <command>./blfs-yes-test1</command> from
253 the command line. It will wait for a response, which can be anything (or
254 nothing) followed by the <keycap>Enter</keycap> key. After entering
255 something, the result will be echoed to the screen. Now use the
256 <command>yes</command> command to automate the entering of a
257 response:</para>
258
259<screen><userinput>yes | ./blfs-yes-test1</userinput></screen>
260
261 <para>Notice that piping <command>yes</command> by itself to the script
262 results in <keycap>y</keycap> being passed to the script. Now try it with a
263 string of text:</para>
264
265<screen><userinput>yes 'This is some text' | ./blfs-yes-test1</userinput></screen>
266
267 <para>The exact string was used as the response to the script. Finally,
268 try it using an empty (null) string:</para>
269
270<screen><userinput>yes '' | ./blfs-yes-test1</userinput></screen>
271
272 <para>Notice this results in passing just the press of the
273 <keycap>Enter</keycap> key to the script. This is useful for times when the
274 default answer to the prompt is sufficient. This syntax is used in the
275 <xref linkend="net-tools-automate-example"/> instructions to accept all the
276 defaults to the many prompts during the configuration step. You may now
277 remove the test script, if desired.</para>
278
279 <bridgehead renderas="sect3">File Redirection to Automate Output</bridgehead>
280
281 <para>In order to automate the building of some packages, especially those
282 that require you to read a license agreement one page at a time, requires
283 using a method that avoids having to press a key to display each page.
284 Redirecting the output to a file can be used in these instances to assist
285 with the automation. The previous section on this page touched on creating
286 log files of the build output. The redirection method shown there used the
287 <command>tee</command> command to redirect output to a file while also
288 displaying the output to the screen. Here, the output will only be sent to
289 a file.</para>
290
291 <para>Again, the easiest way to demonstrate the technique is to show an
292 example. First, issue the command:</para>
293
294<screen><userinput>ls -l /usr/bin | more</userinput></screen>
295
296 <para>Of course, you'll be required to view the output one page at a time
297 because the <command>more</command> filter was used. Now try the same
298 command, but this time redirect the output to a file. The special file
299 <filename>/dev/null</filename> can be used instead of the filename shown,
300 but you will have no log file to examine:</para>
301
302<screen><userinput>ls -l /usr/bin | more &gt; redirect_test.log 2&gt;&amp;1</userinput></screen>
303
304 <para>Notice that this time the command immediately returned to the shell
305 prompt without having to page through the output. You may now remove the
306 log file.</para>
307
308 <para>The last example will use the <command>yes</command> command in
309 combination with output redirection to bypass having to page through the
310 output and then provide a <keycap>y</keycap> to a prompt. This technique
311 could be used in instances when otherwise you would have to page through
312 the output of a file (such as a license agreement) and then answer the
313 question of <quote>do you accept the above?</quote>. For this example,
314 another short <application>Bash</application> script is required:</para>
315
316<screen><userinput>cat &gt; blfs-yes-test2 &lt;&lt; "EOF"
317<literal>#!/bin/bash
318
319ls -l /usr/bin | more
320
321echo -n -e "\n\nDid you enjoy reading this? (y,n) "
322
323read A_STRING
324
325if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key"
326else A_STRING="You did NOT enter the 'y' key"
327fi
328
329echo -e "\n\n$A_STRING\n\n"</literal>
330EOF
331chmod 755 blfs-yes-test2</userinput></screen>
332
333 <para>This script can be used to simulate a program that requires you to
334 read a license agreement, then respond appropriately to accept the
335 agreement before the program will install anything. First, run the script
336 without any automation techniques by issuing
337 <command>./blfs-yes-test2</command>.</para>
338
339 <para>Now issue the following command which uses two automation techniques,
340 making it suitable for use in an automated build script:</para>
341
342<screen><userinput>yes | ./blfs-yes-test2 &gt; blfs-yes-test2.log 2&gt;&amp;1</userinput></screen>
343
344 <para>If desired, issue <command>tail blfs-yes-test2.log</command> to see
345 the end of the paged output, and confirmation that <keycap>y</keycap> was
346 passed through to the script. Once satisfied that it works as it should,
347 you may remove the script and log file.</para>
348
349 <para>Finally, keep in mind that there are many ways to automate and/or
350 script the build commands. There is not a single <quote>correct</quote> way
351 to do it. Your imagination is the only limit.</para>
352
353 </sect2>
354
355 <sect2>
356 <title>Dependencies</title>
357
358 <para>For each package described, BLFS lists the known dependencies.
359 These are listed under several headings, whose meaning is as follows:</para>
360
361 <itemizedlist>
362 <listitem>
363 <para><emphasis>Required</emphasis> means that the target package
364 cannot be correctly built without the dependency having first been
365 installed.</para>
366 </listitem>
367 <listitem>
368 <para><emphasis>Recommended</emphasis> means that BLFS strongly
369 suggests this package is installed first for a clean and trouble-free
370 build, that won't have issues either during the build process, or at
371 run-time. The instructions in the book assume these packages are
372 installed. Some changes or workarounds may be required if these
373 packages are not installed.</para>
374 </listitem>
375 <listitem>
376 <para><emphasis>Optional</emphasis> means that this package might be
377 installed for added functionality. Often BLFS will describe the
378 dependency to explain the added functionality that will result.</para>
379 </listitem>
380 </itemizedlist>
381
382 </sect2>
383
384 <sect2 id="package_updates">
385 <title>Using the Most Current Package Sources</title>
386
387 <para>On occasion you may run into a situation in the book when a package
388 will not build or work properly. Though the Editors attempt to ensure
389 that every package in the book builds and works properly, sometimes a
390 package has been overlooked or was not tested with this particular version
391 of BLFS.</para>
392
393 <para>If you discover that a package will not build or work properly, you
394 should see if there is a more current version of the package. Typically
395 this means you go to the maintainer's web site and download the most current
396 tarball and attempt to build the package. If you cannot determine the
397 maintainer's web site by looking at the download URLs, use Google and query
398 the package's name. For example, in the Google search bar type:
399 'package_name download' (omit the quotes) or something similar. Sometimes
400 typing: 'package_name home page' will result in you finding the
401 maintainer's web site.</para>
402
403 </sect2>
404
405 <sect2 id="stripping">
406 <title>Stripping One More Time</title>
407
408 <para>
409 In LFS, stripping of debugging symbols was discussed a couple of
410 times. When building BLFS packages, there are generally no special
411 instructions that discuss stripping again. It is probably not a good
412 idea to strip an executable or a library while it is in use, so exiting
413 any windowing environment is a good idea. Then you can do:
414 </para>
415
416<screen><userinput>find /{,usr/}{bin,lib,sbin} \
417 -type f \( -name \*.so* -a ! -name \*dbg \) \
418 -exec strip --strip-unneeded {} \;</userinput></screen>
419
420 <para>
421 If you install programs in other directories such as <filename
422 class="directory">/opt</filename> or <filename
423 class="directory">/usr/local</filename>, you may want to strip the files
424 there too.
425 </para>
426
427 <para>
428 For more information on stripping, see <ulink
429 url="http://www.technovelty.org/linux/stripping-shared-libraries.html"/>.
430 </para>
431
432 </sect2>
433<!--
434 <sect2 id="libtool">
435 <title>Libtool files</title>
436
437 <para>
438 One of the side effects of packages that use Autotools, including
439 libtool, is that they create many files with an .la extension. These
440 files are not needed in an LFS environment. If there are conflicts with
441 pkgconfig entries, they can actually prevent successful builds. You
442 may want to consider removing these files periodically:
443 </para>
444
445<screen><userinput>find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete</userinput></screen>
446
447 <para>
448 The above command removes all .la files with the exception of those that
449 have <quote>Image</quote> or <quote>openldap</quote> as a part of the
450 path. These .la files are used by the ImageMagick and openldap programs,
451 respectively. There may be other exceptions by packages not in BLFS.
452 </para>
453
454 </sect2>
455-->
456 <sect2 id="buildsystems">
457 <title>Working with different build systems</title>
458
459 <para>
460 There are now three different build systems in common use for
461 converting C or C++ source code into compiled programs or
462 libraries and their details (particularly, finding out about available
463 options and their default values) differ. It may be easiest to understand
464 the issues caused by some choices (typically slow execution or
465 unexpected use of, or omission of, optimizatons) by starting with
466 the CFLAGS and CXXFLAGS environment variables. There are also some
467 programs which use rust.
468 </para>
469
470 <para>
471 Most LFS and BLFS builders are probably aware of the basics of CFLAGS
472 and CXXFLAGS for altering how a program is compiled. Typically, some
473 form of optimization is used by upstream developers (-O2 or -O3),
474 sometimes with the creation of debug symbols (-g), as defaults.
475 </para>
476
477 <para>
478 If there are contradictory flags (e.g. multiple different -O values),
479 the <emphasis>last</emphasis> value will be used. Sometimes this means
480 that flags specified in environment variables will be picked up before
481 values hardcoded in the Makefile, and therefore ignored. For example,
482 where a user specifies '-O2' and that is followed by '-O3' the build will
483 use '-O3'.
484 </para>
485
486 <para>
487 There are various other things which can be passed in CFLAGS or
488 CXXFLAGS, such as forcing compilation for a specific microarchitecture
489 (e.g. -march=amdfam10, -march=native) or specifying a specific standard
490 for C or C++ (-std=c++17 for example). But one thing which has now come
491 to light is that programmers might include debug assertions in their
492 code, expecting them to be disabled in releases by using -DNDEBUG.
493 Specifically, if <xref linkend="mesa"/> is built with these assertions
494 enabled, some activities such as loading levels of games can take
495 extremely long times, even on high-class video cards.
496 </para>
497
498 <bridgehead renderas="sect3" id="autotools-info">Autotools with Make</bridgehead>
499
500 <para>
501 This combination is often described as 'CMMI' (configure, make, make
502 install) and is used here to also cover the few packages which have a
503 configure script that is not generated by autotools.
504 </para>
505
506 <para>
507 Sometimes running <command>./configure --help</command> will produce
508 useful options about switches which might be used. At other times,
509 after looking at the output from configure you may need to look
510 at the details of the script to find out what it was actually searching
511 for.
512 </para>
513
514 <para>
515 Many configure scripts will pick up any CFLAGS or CXXFLAGS from the
516 environment, but CMMI packages vary about how these will be mixed with
517 any flags which would otherwise be used (<emphasis>variously</emphasis>:
518 ignored, used to replace the programmer's suggestion, used before the
519 programmer's suggestion, or used after the programmer's suggestion).
520 </para>
521
522 <para>
523 In most CMMI packages, running 'make' will list each command and run
524 it, interspersed with any warnings. But some packages try to be 'silent'
525 and only show which file they are compiling or linking instead of showing
526 the command line. If you need to inspect the command, either because of
527 an error, or just to see what options and flags are being used, adding
528 'V=1' to the make invocation may help.
529 </para>
530
531 <bridgehead renderas="sect3" id="cmake-info">CMake</bridgehead>
532
533 <para>
534 CMake works in a very different way, and it has two backends which can
535 be used on BLFS: 'make' and 'ninja'. The default backend is make, but
536 ninja can be faster on large packages with multiple processors. To
537 use ninja, specify '-G Ninja' in the cmake command. However, there are
538 some packages which create fatal errors in their ninja files but build
539 successfully using the default of Unix Makefiles.
540 </para>
541
542 <para>
543 The hardest part of using CMake is knowing what options you might wish
544 to specify. The only way to get a list of what the package knows about
545 is to run <command>cmake -LAH</command> and look at the output for that
546 default configuration.
547 </para>
548
549 <para>
550 Perhaps the most-important thing about CMake is that it has a variety
551 of CMAKE_BUILD_TYPE values, and these affect the flags. The default
552 is that this is not set and no flags are generated. Any CFLAGS or
553 CXXFLAGS in the environment will be used. If the programmer has coded
554 any debug assertions, those will be enabled unless -DNDEBUG is used.
555 The following CMAKE_BUILD_TYPE values will generate the flags shown,
556 and these will come <emphasis>after</emphasis> any flags in the
557 environment and therefore take precedence.
558 </para>
559
560 <itemizedlist>
561 <listitem>
562 <para>Debug : '-g'</para>
563 </listitem>
564 <listitem>
565 <para>Release : '-O3 -DNDEBUG'</para>
566 </listitem>
567 <listitem>
568 <para>RelWithDebInfo : '-O2 -g -DNDEBUG'</para>
569 </listitem>
570 <listitem>
571 <para>MinSizeRel : '-Os -DNDEBUG'</para>
572 </listitem>
573 </itemizedlist>
574
575 <para>
576 CMake tries to produce quiet builds. To see the details of the commands
577 which are being run, use 'make VERBOSE=1' or 'ninja -v'.
578 </para>
579
580 <bridgehead renderas="sect3" id="meson-info">Meson</bridgehead>
581
582 <para>
583 Meson has some similarities to CMake, but many differences. To get
584 details of the defines that you may wish to change you can look at
585 <filename>meson_options.txt</filename> which is usually in the
586 top-level directory.
587 </para>
588
589 <para>
590 If you have already configured the package by running
591 <command>meson</command> and now wish to change one or more settings,
592 you can either remove the build directory, recreate it, and use the
593 altered options, or within the build directory run <command>meson
594 configure</command>, e.g. to set an option:
595 </para>
596
597<screen><userinput>meson configure -D&lt;some_option&gt;=true</userinput></screen>
598
599 <para>
600 If you do that, the file <filename>meson-private/cmd_line.txt</filename>
601 will show the <emphasis>last</emphasis> commands which were used.
602 </para>
603
604 <para>
605 Meson provides the following buildtype values, and the flags they enable
606 come <emphasis>after</emphasis> any flags supplied in the environment and
607 therefore take precedence.
608 </para>
609
610 <itemizedlist>
611 <listitem>
612 <para>plain : no added flags. This is for distributors to supply their
613 own CLFAGS, CXXFLAGS and LDFLAGS. There is no obvious reason to use
614 this in BLFS.</para>
615 </listitem>
616 <listitem>
617 <para>debug : '-g'</para>
618 </listitem>
619 <listitem>
620 <para>debugoptimized : '-O2 -g' - this is the default if nothing is
621 specified, it leaves assertions enabled.</para>
622 </listitem>
623 <listitem>
624 <para>release : '-O3 -DNDEBUG' (but occasionally a package will force
625 -O2 here)</para>
626 </listitem>
627 </itemizedlist>
628
629 <para>
630 Although the 'release' buildtype is described as enabling -DNDEBUG, and all
631 CMake Release builds pass that, it has so far only been observed (in
632 verbose builds) for <xref linkend="mesa"/>. That suggests that it might
633 only be used when there are debug assertions present.
634 </para>
635
636 <para>
637 The -DNDEBUG flag can also be provided by passing
638 <command>-Db_ndebug=true</command>.
639 </para>
640
641 <para>
642 To see the details of the commands which are being run in a package using
643 meson, use 'ninja -v'.
644 </para>
645
646 <bridgehead renderas="sect3" id="rust-info">Rustc and Cargo</bridgehead>
647
648 <para>
649 Most released rustc programs are provided as crates (source tarballs)
650 which will query a server to check current versions of dependencies
651 and then download them as necessary. These packages are built using
652 <command>cargo --release</command>. In theory, you can manipulate the
653 RUSTFLAGS to change the optimize-level (default is 3, like -O3, e.g.
654 <literal>-Copt-level=3</literal>) or to force it to build for the
655 machine it is being compiled on, using
656 <literal>-Ctarget-cpu=native</literal> but in practice this seems to
657 make no significant difference.
658 </para>
659
660 <para>
661 If you find an interesting rustc program which is only provided as
662 unpackaged source, you should at least specify
663 <literal>RUSTFLAGS=-Copt-level=2</literal> otherwise it will do an
664 unoptimized compile with debug info and run <emphasis>much</emphasis>
665 slower.
666 </para>
667
668 </sect2>
669
670 <sect2 id="optimizations">
671 <title>Optimizing the build</title>
672
673 <para>
674 Many people will prefer to optimize compiles as they see fit, by providing
675 CFLAGS or CXXFLAGS. For an introduction to the options available with gcc
676 and g++ see <ulink
677 url="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html"/> and <ulink
678 url="https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html"/>
679 and <command>info gcc</command>.
680
681 </para>
682
683 <para>
684 Some packages default to '-O2 -g', others to '-O3 -g', and if CFLAGS or
685 CXXFLAGS are supplied they might be added to the package's defaults,
686 replace the package's defaults, or even be ignored. There are details
687 on some desktop packages which were mostly current in April 2019 at
688 <ulink url="http://www.linuxfromscratch.org/~ken/tuning/"/> - in
689 particular, README.txt, tuning-1-packages-and-notes.txt, and
690 tuning-notes-2B.txt. The particular thing to remember is that if you
691 want to try some of the more interesting flags you may need to force
692 verbose builds to confirm what is being used.
693 </para>
694
695 <para>
696 Clearly, if you are optimizing your own program you can spend time to
697 profile it and perhaps recode some of it if it is too slow. But for
698 building a whole system that approach is impractical. In general,
699 -O3 usually produces faster programs than -O2. Specifying
700 -march=native is also beneficial, but means that you cannot move the
701 binaries to an incompatible machine - this can also apply to newer
702 machines, not just to older machines. For example programs compiled for
703 'amdfam10' run on old Phenoms, Kaveris, and Ryzens : but programs
704 compiled for a Kaveri will not run on a Ryzen because certain op-codes
705 are not present. Similarly, if you build for a Haswell not everything
706 will run on a SandyBridge.
707 </para>
708
709 <para>
710 There are also various other options which some people claim are
711 beneficial. At worst, you get to recompile and test, and then
712 discover that in your usage the options do not provide a benefit.
713 </para>
714
715 <para>
716 If building Perl or Python modules, or Qt packages which use qmake,
717 in general the CFLAGS and CXXFLAGS used are those which were used by
718 those 'parent' packages.
719 </para>
720
721 </sect2>
722
723 <sect2 id="hardening">
724 <title>Options for hardening the build</title>
725
726 <para>
727 Even on desktop systems, there are still a lot of exploitable
728 vulnerabilities. For many of these, the attack comes via javascript
729 in a browser. Often, a series of vulnerabilities are used to gain
730 access to data (or sometimes to pwn, i.e. own, the machine and
731 install rootkits). Most commercial distros will apply various
732 hardening measures.
733 </para>
734
735 <para>
736 For hardening options which are reasonably cheap, there is some
737 discussion in the 'tuning' link above (occasionally, one or more
738 of these options might be inappropriate for a package). These
739 options are -D_FORTIFY_SOURCE=2, -fstack-protector=strong, and
740 (for C++) -D_GLIBCXX_ASSERTIONS. On modern machines these should
741 only have a little impact on how fast things run, and often they
742 will not be noticeable.
743 </para>
744
745 <para>
746 In the past, there was Hardened LFS where gcc (a much older version)
747 was forced to use hardening (with options to turn some of it off on a
748 per-package basis. What is being covered here is different - first you
749 have to make sure that the package is indeed using your added flags and
750 not over-riding them.
751 </para>
752
753 <para>
754 The main distros use much more, such as RELRO (Relocation Read Only)
755 and perhaps -fstack-clash-protection. You may also encounter the
756 so-called 'userspace retpoline' (-mindirect-branch=thunk etc.) which
757 is the equivalent of the spectre mitigations applied to the linux
758 kernel in late 2018). The kernel mitigations caused a lot of complaints
759 about lost performance, if you have a production server you might wish
760 to consider testing that, along with the other available options, to
761 see if performance is still sufficient.
762 </para>
763
764 <para>
765 Whilst gcc has many hardening options, clang/LLVM's strengths lie
766 elsewhere. Some options which gcc provides are said to be less effective
767 in clang/LLVM, others are not available.
768 </para>
769
770 </sect2>
771
772</sect1>
Note: See TracBrowser for help on using the repository browser.