• A family of tools, which associated together form a complete and extensible build system
    • autoconf is used to handle the configuration of the software package
    • automake is used to generate the Makefiles needed to build the software package
    • pkgconfig is used to ease compilation against already installed shared libraries
    • libtool is used to handle the generation of shared libraries in a system-independent way
  • Most of these tools are old and relatively complicated to use, but they are used by a majority of free software packages today. One must have a basic understanding of what they do and how they work.

automake / autoconf / autoheader

automake / autoconf

  • Files written by the developer
    • describes the configuration options and the checks done at configure time
    • describes how the software should be built
  • The configure script and the files are generated by autoconf and automake respectively.
    • They should never be modified directly
    • They are usually shipped pre-generated in the software package, because there are several versions of autoconf and automake, and they are not completely compatible
  • The Makefile files are generated at configure time, before compiling
    • They are never shipped in the software package.

Configuring and compiling: native case

  • The traditional steps to configure and compile an autotools based package are
    • Configuration of the package ./configure
    • Compilation of the package make
    • Installation of the package make install
  • Additional arguments can be passed to the ./configure script to adjust the component configuration.
  • Only the make install needs to be done as root if the installation should take place system-wide

Configuring and compiling: cross case

  • For cross-compilation, things are a little bit more complicated.
  • At least some of the environment variables AR, AS, LD, NM, CC, GCC, CPP, CXX, STRIP, OBJCOPY must be defined to point to the proper cross-compilation tools. The host tuple is also by default used as prefix.
  • configure script arguments:
  • --host: mandatory but a bit confusing. Corresponds to the target platform the code will run on. Example:
    • --host=arm-linux
    • --build: build system. Automatically detected.
    • --target is only for tools generating code.
  • It is recommended to pass the --prefix argument. It defines from which location the software will run in the target environment. Usually, /usr is fine.

  • If one simply runs make install, the software will be installed in the directory passed as --prefix. For cross-compiling, one must pass the DESTDIR argument to specify where the software must be installed.

  • Making the distinction between the prefix (as passed with --prefix at configure time) and the destination directory (as passed with DESTDIR at installation time) is very important.

  • Example: export PATH=/usr/local/arm-linux/bin:$PATH export CC=arm-linux-gcc export STRIP=arm-linux-strip ./configure --host=arm-linux --prefix=/usr make make DESTDIR=$HOME/work/rootfs install


  • The autotools based software packages provide both a install and install-strip make targets, used to install the software, either stripped or unstripped.
  • For applications, the software is usually installed in /bin, with configuration files in /etc and data in /share//
  • The case of libraries is a little more complicated:
    • In /lib, the library itself (a .so.), a few symbolic links, and the libtool description file (a .la file)
    • The pkgconfig description file in /lib/pkgconfig
    • Include files in /include/
    • Sometimes a -config program in /bin
    • Documentation in /share/man or /share/doc/

Contents of usr/lib after installation of libpng and zlib

  • libpng libtool description files ./lib/ ./lib/ ->
  • libpng static version ./lib/libpng12.a ./lib/libpng.a -> libpng12.a
  • libpng dynamic version ./lib/ ./lib/ ./lib/ -> ./lib/ -> ./lib/ -> ./lib/ ->
  • libpng pkg-config description files ./lib/pkgconfig/libpng12.pc ./lib/pkgconfig/libpng.pc -> libpng12.pc
  • zlib dynamic version ./lib/ ./lib/ -> ./lib/ ->

Installation in the build and target spaces

  • From all these files, everything except documentation is necessary to build an application that relies on libpng.
    • These files will go into the build space
  • However, only the library .so binaries in /lib and some symbolic links are needed to execute the application on the target.
    • Only these files will go in the target space
  • The build space must be kept in order to build other applications or recompile existing applications.


  • pkg-config is a tool that allows to query a small database to get information on how to compile programs that depend on libraries
  • The database is made of .pc files, installed by default in /lib/pkgconfig/.
  • pkg-config is used by the configure script to get the library configurations
  • It can also be used manually to compile an application: arm-linux-gcc -o test test.c $(pkg-config --libs --cflags thelib)
  • By default, pkg-config looks in /usr/lib/pkgconfig for the *.pc files, and assumes that the paths in these files are correct.
  • PKG_CONFIG_PATH allows to set another location for the *.pc files and PKG_CONFIG_SYSROOT_DIR to prepend a prefix to the paths mentioned in the .pc files.

Find the libraries

  • When compiling an application or a library that relies on other libraries, the build process by default looks in /usr/lib for libraries and /usr/include for headers.
  • The first thing to do is to set the CFLAGS and LDFLAGS environment variables: export CFLAGS=-I/my/build/space/usr/include/ export LDFLAGS=-L/my/build/space/usr/lib
  • The libtool files (.la files) must be modified because they include the absolute paths of the libraries:
    • libdir='/usr/lib'
    • libdir='/my/build/space/usr/lib'
  • The PKG_CONFIG_PATH environment variable must be set to the location of the .pc files and the PKG_CONFIG_SYSROOT_DIR variable must be set to the build space directory.

results matching ""

    No results matching ""