Brian Gough’s Notes

Archive for April, 2011

Some pre-release checks for GNU packages

Monday, April 4th, 2011

Here’s a list of pre-release checks I’ve found useful over the years. Most of them should apply to any package, but they’ve been used for a C library (“libfoo” in the examples below, with exported header files foo/*.h and source files src/*.c).

  • Make sure all internal functions are static, and all exported functions & variables prefixed with foo_ or FOO_. Here’s a command for checking this:
    nm -A -g -P *.a  | perl -a -n -e 'print if $F[1] !~ /foo_/ && $F[2] ne "U"'
  • Make sure config.h is used consistently – it should be present in source files, but not in any exported headers.
    grep config.h foo/*.h    --- shouldn't match anything
    grep -L config.h src/*.c   --- gives files not using config.h
  • Make a master header file of all exported headers and try compiling it to test for conflicts between different header files.
    cat foo/*.h > tmp.c
    gcc tmp.c
  • Check that the library passes “make check” with various options. Some good ones are:
    -mfpmath=sse -msse2
    -funsigned-char (to simulate Power/ARM)
    -std=c89 -ansi -pedantic (now that GCC uses c99 by default instead of c89)
  • Test with valgrind. You can run all the tests under valgrind with the TESTS_ENVIRONMENT variable
     $ TESTS_ENVIRONMENT="valgrind --tool=memcheck" make check

    This only works if configure was run with –disable-shared, because otherwise the shared library libtool shell-scripts themselves are run under valgrind.

    Regarding memory leaks, the GNU coding standards say “Memory leak detectors such as valgrind can be useful, but don’t complicate a program merely to avoid their false alarms. For example, if memory is used until just before a process exits, don’t free it simply to silence a leak detector.”

    For libraries I’ve found it’s very helpful (actually, essential) to have a test suite that is leak-free. Then if any test program exits with memory still allocated it indicates a problem. This is how I have caught any memory leaks during development.

  • Do make distcheck the local copy of install-sh provided by automake, in addition to /usr/bin/install. Depending on the end user’s environment, either of these could end up being used.
    make distcheck # will use /usr/bin/install
    make distcheck INSTALL=$HOME/foo/install-sh  # absolute location of install-sh

    When you do “make install” yourself, it will probably use /usr/bin/install since that is present on GNU/Linux systems. If so, you would not detect any problem with the install-sh shipped in your package – for example, if it had got corrupted for some reason (e.g. a stray edit or in my case, after doing a repository conversion I somehow ended up with my working directory containing the first ever version of install-sh that was checked in – which dated from 1994 – it didn’t work properly on modern systems, but I never noticed that because I was always using /usr/bin/install).

  • Try running the build and make check with a memory limit to be sure that excessive memory is not required to do the compilation.
    ulimit -v 65536  #  some reasonable memory limit
    make check
  • Check that the texinfo manual works for postscript/pdf
    make dvi  # or make pdf

    It’s easy to miss a diagram or other texinput file that is needed by texi2dvi but not by makeinfo.