Autotools

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

Files written by the developer
- configure.in describes the configuration options and the checks done at configure time
- Makefile.am describes how the software should be built
The configure script and the Makefile.in 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.

The traditional steps to conﬁgure and compile an autotools based package are
- Conﬁguration 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 conﬁguration.
Only the make install needs to be done as root if the installation should take place system-wide

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 deﬁned to point to the proper cross-compilation tools. The host tuple is also by default used as preﬁx.
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 deﬁnes from which location the software will run in the target environment. Usually, /usr is ﬁne.
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 preﬁx (as passed with --prefix at conﬁgure 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 conﬁguration ﬁles 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 ﬁle (a .la ﬁle)
- The pkgconﬁg description ﬁle in /lib/pkgconfig
- Include ﬁles 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 ﬁles ./lib/libpng12.la ./lib/libpng.la -> libpng12.la
libpng static version ./lib/libpng12.a ./lib/libpng.a -> libpng12.a
libpng dynamic version ./lib/libpng.so.3.32.0 ./lib/libpng12.so.0.32.0 ./lib/libpng12.so.0 -> libpng12.so.0.32.0 ./lib/libpng12.so -> libpng12.so.0.32.0 ./lib/libpng.so -> libpng12.so ./lib/libpng.so.3 -> libpng.so.3.32.0
libpng pkg-conﬁg description ﬁles ./lib/pkgconfig/libpng12.pc ./lib/pkgconfig/libpng.pc -> libpng12.pc
zlib dynamic version ./lib/libz.so.1.2.3 ./lib/libz.so -> libz.so.1.2.3 ./lib/libz.so.1 -> libz.so.1.2.3

From all these ﬁles, everything except documentation is necessary to build an application that relies on libpng.
- These ﬁles 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 ﬁles 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 ﬁles, installed by default in /lib/pkgconfig/.
pkg-config is used by the configure script to get the library conﬁgurations
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 ﬁles, and assumes that the paths in these ﬁles are correct.
PKG_CONFIG_PATH allows to set another location for the *.pc ﬁles and PKG_CONFIG_SYSROOT_DIR to prepend a preﬁx to the paths mentioned in the .pc ﬁles.

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 ﬁrst 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 ﬁles (.la ﬁles) must be modiﬁed 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 ﬁles and the PKG_CONFIG_SYSROOT_DIR variable must be set to the build space directory.