Build Log HOWTO

Introduction

Creating a Slackware package from scratch means you have to find out how the source code you're packaging behaves during the compile.

A bugfree application code with a flawless Makefile will result in a clean build process and a ready-to-use Slackware package. Unfortunately, we do not live in an ideal programming world, and you will often encounter source code archives that will not compile out of the box or will not cleanly install into a directory you specify in your SlackBuild (like when you run make install DESTDIR=$PKG).

This is the moment you want to enable logging of your SlackBuild's actions and results, so that you can comfortably search through the logfiles when there appears to be a problem with building your new package.

- 1 - Logging Everything

One method is to just log the entire output of your SlackBuild script to a file. The command you would use for a program called 'foo' looks like this:

./foo.SlackBuild 2>&1 | tee build-foo.log

The part " | tee build-foo.log" causes a file build-foo.log to be created (if it does not yet exist) and a copy of the text that your script displays on the console is going to be written to it. Any previous content of that logfile will be overwritten.

The part "2>&1" means that you will also catch the ERROR output of failed commands. You would normally not notice, but programs can write their output to "standard output" as well as "error output". These are two separate "channels" if you like, and since the tee command will only catch "standard output" and duplicate it into the target file, you will have to explicitly add "error output" as well. Remember, the error output will often be the stuff you're most interested in!

By using this command, you are still able to watch the proceedings of the package build process on your console, and afterwards you can open the log file in an editor at your leisure. The console's scrollback buffer will often prove to be too small to keep the full output of the package build process.

- 2 - Logging Selectively

Another method, which you can use in addition to the previously described logging method if you want, is to add tee commands inside your SlackBuild as well. This will enable you to do a more targeted logging. For instance, I am often most interested in the log of the configure and the make install commands and try to catch their output in separate files. Problems with the make command are easily found by "grepping" for words like "fail" and "error," but weirdness in the configure stage or when installing files to the $PKG directory can not be caught so easily.

Logging the output from the configure command:
Add the text " 2>&1 | tee configure-$PRGNAM.log" at the end of the configure command. An typical configure command line would look like this:

./configure --prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
2>&1 | tee configure-${PRGNAM}.log

The backslashes (\) at the end of all lines except the last, are continuation characters: the backslash tells the shell that the command which started with ./configure continues on the next line.

Logging the output from the make install command:
Add the text " 2>&1 | tee install-$PRGNAM.log" at the end of the make install command line. An example:

make install DESTDIR=$PKG 2>&1 |tee install-${PRGNAM}.log

If you have the 'installwatch' program installed, then you can get a more easily readable logging of the make install command. Installwatch is part of the checkinstall package which you find in the "/extra" section of your Slackware CD set. The logfile of installwatch is much more to the point, and makes it easier to spot files that get copied outside the package root directory, "$PKG". The command would then become:

installwatch -o install-${PRGNAM}.log make install DESTDIR=$PKG

- 3 - What To Look For

Things to look for in the log files when the package appears to be broken:

During 'configure':

  • Parameters to 'configure' that are wrong
  • Dependencies that are not fullfilled (other required software either not present or with a version that is too old)
  • Unwanted dependencies that are picked up because you have installed 3rd party software that your new package will want to use if it is found.
    • NOTE: This is where most packages fail to work for other people than the packager. You should try to build packages that are meant for redistribution either on a very clean Slackware system, or explicitly add the software dependencies as comments with the package.

During 'make':

  • Compilation errors ( grep -iE "(error|failed)" )
  • Header/include/library files missing ( grep -iE "(not found|unavailable)" )

During 'make install'

  • Files that are installed outside the package root $PKG. Suppose $PKG expands to the directory /tmp/package-foo; you will easily spot problems when you run this command (assuming you used installwatch to produce the logfile):
    cat install-foo.log | grep -v "package-foo" | grep -v "/dev/null" | grep -v "/dev/tty"

Written by Eric Hameleers (alien@slackware.com) :: 02-jun-2006

[  Exec: 0.0281 sec  |  Load: 0.16 0.10 0.07  ]

© 2006-2014 SlackBuilds.org Project. All rights reserved.
Slackware® is a registered trademark of Patrick Volkerding
Linux® is a registered trademark of Linus Torvalds
Web Design by WebSight Designs |  Managed Hosting by OnyxLight Communications