%general-entities; ]> $LastChangedBy: bdubbs $ $Date: 2014-08-24 13:00:46 -0400 (Sun, 24 Aug 2014) $ Those people who have built an LFS system may be aware of the general principles of downloading and unpacking software. Some of that information is repeated here for those new to building their own software. Each set of installation instructions contains a URL from which you can download the package. The patches; however, are stored on the LFS servers and are available via HTTP. These are referenced as needed in the installation instructions. While you can keep the source files anywhere you like, we assume that you have unpacked the package and changed into the directory created by the unpacking process (the 'build' directory). We also assume you have uncompressed any required patches and they are in the directory immediately above the 'build' directory. We can not emphasize strongly enough that you should start from a clean source tree each time. This means that if you have had an error during configuration or compilation, it's usually best to delete the source tree and re-unpack it before trying again. This obviously doesn't apply if you're an advanced user used to hacking Makefiles and C code, but if in doubt, start from a clean tree. The golden rule of Unix System Administration is to use your superpowers only when necessary. Hence, BLFS recommends that you build software as an unprivileged user and only become the root user when installing the software. This philosophy is followed in all the packages in this book. Unless otherwise specified, all instructions should be executed as an unprivileged user. The book will advise you on instructions that need root privileges. If a file is in .tar format and compressed, it is unpacked by running one of the following commands: tar -xvf filename.tar.gz tar -xvf filename.tgz tar -xvf filename.tar.Z tar -xvf filename.tar.bz2 You may omit using the v parameter in the commands shown above and below if you wish to suppress the verbose listing of all the files in the archive as they are extracted. This can help speed up the extraction as well as make any errors produced during the extraction more obvious to you. You can also use a slightly different method: bzcat filename.tar.bz2 | tar -xv Finally, you sometimes need to be able to unpack patches which are generally not in .tar format. The best way to do this is to copy the patch file to the parent of the 'build' directory and then run one of the following commands depending on whether the file is a .gz or .bz2 file: gunzip -v patchname.gz bunzip2 -v patchname.bz2 Generally, to verify that the downloaded file is genuine and complete, many package maintainers also distribute md5sums of the files. To verify the md5sum of the downloaded files, download both the file and the corresponding md5sum file to the same directory (preferably from different on-line locations), and (assuming file.md5sum is the md5sum file downloaded) run the following command: md5sum -c file.md5sum If there are any errors, they will be reported. Note that the BLFS book includes md5sums for all the source files also. To use the BLFS supplied md5sums, you can create a file.md5sum (place the md5sum data and the exact name of the downloaded file on the same line of a file, separated by white space) and run the command shown above. Alternately, simply run the command shown below and compare the output to the md5sum data shown in the BLFS book. md5sum <name_of_downloaded_file> For larger packages, it is convenient to create log files instead of staring at the screen hoping to catch a particular error or warning. Log files are also useful for debugging and keeping records. The following command allows you to create an installation log. Replace <command> with the command you intend to execute. ( <command> 2>&1 | tee compile.log && exit $PIPESTATUS ) 2>&1 redirects error messages to the same location as standard output. The tee command allows viewing of the output while logging the results to a file. The parentheses around the command run the entire command in a subshell and finally the exit $PIPESTATUS command ensures the result of the <command> is returned as the result and not the result of the tee command. There are times when automating the building of a package can come in handy. Everyone has their own reasons for wanting to automate building, and everyone goes about it in their own way. Creating Makefiles, Bash scripts, Perl scripts or simply a list of commands used to cut and paste are just some of the methods you can use to automate building BLFS packages. Detailing how and providing examples of the many ways you can automate the building of packages is beyond the scope of this section. This section will expose you to using file redirection and the yes command to help provide ideas on how to automate your builds. File Redirection to Automate Input You will find times throughout your BLFS journey when you will come across a package that has a command prompting you for information. This information might be configuration details, a directory path, or a response to a license agreement. This can present a challenge to automate the building of that package. Occasionally, you will be prompted for different information in a series of questions. One method to automate this type of scenario requires putting the desired responses in a file and using redirection so that the program uses the data in the file as the answers to the questions. Building the CUPS package is a good example of how redirecting a file as input to prompts can help you automate the build. If you run the test suite, you are asked to respond to a series of questions regarding the type of test to run and if you have any auxiliary programs the test can use. You can create a file with your responses, one response per line, and use a command similar to the one shown below to automate running the test suite: make check < ../cups-1.1.23-testsuite_parms This effectively makes the test suite use the responses in the file as the input to the questions. Occasionally you may end up doing a bit of trial and error determining the exact format of your input file for some things, but once figured out and documented you can use this to automate building the package. Using yes to Automate Input Sometimes you will only need to provide one response, or provide the same response to many prompts. For these instances, the yes command works really well. The yes command can be used to provide a response (the same one) to one or more instances of questions. It can be used to simulate pressing just the Enter key, entering the Y key or entering a string of text. Perhaps the easiest way to show its use is in an example. First, create a short Bash script by entering the following commands: cat > blfs-yes-test1 << "EOF" #!/bin/bash echo -n -e "\n\nPlease type something (or nothing) and press Enter ---> " read A_STRING if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed" else A_STRING="You entered '$A_STRING'" fi echo -e "\n\n$A_STRING\n\n" EOF chmod 755 blfs-yes-test1 Now run the script by issuing ./blfs-yes-test1 from the command line. It will wait for a response, which can be anything (or nothing) followed by the Enter key. After entering something, the result will be echoed to the screen. Now use the yes command to automate the entering of a response: yes | ./blfs-yes-test1 Notice that piping yes by itself to the script results in y being passed to the script. Now try it with a string of text: yes 'This is some text' | ./blfs-yes-test1 The exact string was used as the response to the script. Finally, try it using an empty (null) string: yes '' | ./blfs-yes-test1 Notice this results in passing just the press of the Enter key to the script. This is useful for times when the default answer to the prompt is sufficient. This syntax is used in the instructions to accept all the defaults to the many prompts during the configuration step. You may now remove the test script, if desired. File Redirection to Automate Output In order to automate the building of some packages, especially those that require you to read a license agreement one page at a time, requires using a method that avoids having to press a key to display each page. Redirecting the output to a file can be used in these instances to assist with the automation. The previous section on this page touched on creating log files of the build output. The redirection method shown there used the tee command to redirect output to a file while also displaying the output to the screen. Here, the output will only be sent to a file. Again, the easiest way to demonstrate the technique is to show an example. First, issue the command: ls -l /usr/bin | more Of course, you'll be required to view the output one page at a time because the more filter was used. Now try the same command, but this time redirect the output to a file. The special file /dev/null can be used instead of the filename shown, but you will have no log file to examine: ls -l /usr/bin | more > redirect_test.log 2>&1 Notice that this time the command immediately returned to the shell prompt without having to page through the output. You may now remove the log file. The last example will use the yes command in combination with output redirection to bypass having to page through the output and then provide a y to a prompt. This technique could be used in instances when otherwise you would have to page through the output of a file (such as a license agreement) and then answer the question of do you accept the above?. For this example, another short Bash script is required: cat > blfs-yes-test2 << "EOF" #!/bin/bash ls -l /usr/bin | more echo -n -e "\n\nDid you enjoy reading this? (y,n) " read A_STRING if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key" else A_STRING="You did NOT enter the 'y' key" fi echo -e "\n\n$A_STRING\n\n" EOF chmod 755 blfs-yes-test2 This script can be used to simulate a program that requires you to read a license agreement, then respond appropriately to accept the agreement before the program will install anything. First, run the script without any automation techniques by issuing ./blfs-yes-test2. Now issue the following command which uses two automation techniques, making it suitable for use in an automated build script: yes | ./blfs-yes-test2 > blfs-yes-test2.log 2>&1 If desired, issue tail blfs-yes-test2.log to see the end of the paged output, and confirmation that y was passed through to the script. Once satisfied that it works as it should, you may remove the script and log file. Finally, keep in mind that there are many ways to automate and/or script the build commands. There is not a single correct way to do it. Your imagination is the only limit. For each package described, BLFS lists the known dependencies. These are listed under several headings, whose meaning is as follows: Required means that the target package cannot be correctly built without the dependency having first been installed. Recommended means that BLFS strongly suggests this package is installed first for a clean and trouble-free build, that won't have issues either during the build process, or at run-time. The instructions in the book assume these packages are installed. Some changes or workarounds may be required if these packages are not installed. Optional means that this package might be installed for added functionality. Often BLFS will describe the dependency to explain the added functionality that will result. On occasion you may run into a situation in the book when a package will not build or work properly. Though the Editors attempt to ensure that every package in the book builds and works properly, sometimes a package has been overlooked or was not tested with this particular version of BLFS. If you discover that a package will not build or work properly, you should see if there is a more current version of the package. Typically this means you go to the maintainer's web site and download the most current tarball and attempt to build the package. If you cannot determine the maintainer's web site by looking at the download URLs, use Google and query the package's name. For example, in the Google search bar type: 'package_name download' (omit the quotes) or something similar. Sometimes typing: 'package_name home page' will result in you finding the maintainer's web site. In LFS, stripping of debugging symbols was discussed a couple of times. When building BLFS packages, there are generally no special instructions that discuss stripping again. It is probably not a good idea to strip an executable or a library while it is in use, so exiting any windowing environment is a good idea. Then you can do: find /{,usr/}{bin,lib,lib32,libx32,sbin} -type f -exec strip --strip-unneeded {} \; If you install programs in other directories such as /opt or /usr/local, you may want to strip the files there too. For more information on stripping, see . One of the side effects of packages that use Autotools, including libtool, is that they create many files with an .la extension. These files are not needed in an LFS environment. If there are conflicts with pkgconfig entries, they can actually prevent successful builds. You may want to consider removing these files periodically: find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete The above command removes all .la files with the exception of those that have "Image" as a part of the path. These .la files are used by the ImageMagick programs. There may be other exceptions by packages not in BLFS.