Don't Fear the Autotools!

Scott GarmanPortland Linux User GroupDecember 1, 2011

AC_INIT([Scott Garman], [1.0], [sgarman@zenlinux.com])

● Embedded Linux SW Engineer at Intel● Working on the Yocto Project (yoctoproject.org)● I am not an Autotools fanboy; just a pragmatic user● I do not really know all that much about Autotools● It's just that knowing just enough about Autotools to be

able to effectively work with it is a lot more than most people tend to know about it

● This is a “gentle introduction” to hopefully inspire further study

What are “the Autotools?”

● Cross-platform build system for compiled software (typically C/C++ applications)

● Helps to encourage portability standards defined in the GNU Coding Standards (GCS) and Filesystem Hierarchy Standard (FHS)

● The tools:● Autoconf● Automake● Libtool

From a User's Perspective

● tar xvzf application-1.0.tar.gz● cd application-1.0/● ./configure● make● sudo make install

The Most Common Configure Error

● Configure script fails and reports an error such as: “No package libfoo found”

● This indicates that you need to install library foo● “But I already have a package named libfoo

installed!”● The runtime library is installed from package

libfoo, but to compile applications which use foo, you need to install the “development headers” - this package is generally named libfoo-dev or libfoo-devel

Troubleshooting Configure Errors

● When configure is run, it generates a log file config.log, which contains:● Command line used to invoke configure● Platform information about your environment● Additional details about the tests configure ran● A line number from the configure script where config.status is generated and run

● Submitting config.log with a bug report to the application maintainers gives them important information they need to fix the issue

config.status

● Uses information from configure to perform substitutions in *.in template files to generate the output files:

configure

config.status

config.h.in config.h

Makefile.in Makefile

config.log

config.site

● Running configure tests can take a while

● If you're installing many apps from source, you'll be running a lot of the same tests over and over again

● Things like the size of a long int are not going to change on your system

● A config.site file can be created with seeded values for these tests, and will be used as a test result “cache”

● Set an environment var CONFIG_SITE with the path to your config.site file to make use of it

● Very handy when cross-compiling apps (since some tests compile small C programs, but those programs can't be run natively!)

Filesystem Hierarchy Standard (FHS)

● Defines root filesystem layout guidelines and where various file types belong

● For example: the difference between binaries in /sbin vs. /usr/sbin

● Widespread adoption by GNU/Linux distros has made portability of build systems easier

● Current version is 2.3 (from 2004); v3.0 is now available in draft form

● http://www.pathname.com/fhs/

GNU Coding Standards (GCS)

● How source build configuration should work● Defines standard Makefile targets (install, dist,

check, installcheck, etc)● Defines standard directory variables (bindir,

libexecdir, sysconfdir, etc)● Standard command-line options (to promote

consistent behavior among GNU utilities)● Good advice for how to write portable C code● http://www.gnu.org/prep/standards/

From a Developer's Perspective

● Autoconf:

configure

config.status

config.h.in config.h

Makefile.in Makefile

config.log

configure.ac autoconf/autoreconf

From a Developer's Perspective

● Automake:

configure

config.status

config.h.in config.h

Makefile.in Makefile

config.log

configure.ac autoconf/autoreconf

automake/autoreconf Makefile.am

Hello World Example

● Let's take a look at how to take a trivial C program (GNU amhello) and enable basic Autotools support

Libtool

● Differences in how shared libraries are built across Unix systems are especially challenging to deal with

● Very specific and unique compiler options are often needed on different platforms

● Differences in library naming conventions● Libtool abstracts these details into a wrapper

script that is invoked in uniform fashion to build libraries

Libtool Utilities

● libtool – generic example script● libtoolize – creates a custom version of the

libtool script that works with your program (ltmain.sh); you then include this when distributing your sources

● ltdl/ltdl.h – A standard way of loading shared libraries on-demand within your application (for when you want control over the process)

Why Use Autotools?

● Attempting to address all of the subtle build failures that can occur between platforms yourself is an exercise in futility

● Leverage the collective wisdom the project has attained, to result in portable shell scripts and makefiles which have minimal system requirements

● Built-in support for following the GNU Coding Standards and FHS

● Users and distro maintainers expect these features and already understand an Autotools-based build process

Resources

● Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool, by John Calcote. No Starch Press.

● Autotools Tutorial by Alexandre Duret-Lutz: http://www.lrde.epita.fr/~adl/autotools.html

● GNU Coding Standards: http://www.gnu.org/prep/standards/

● Filesystem Hierarchy Standard: http://www.pathname.com/fhs/

● Autoconf Macro Definitions:

http://www.gnu.org/software/autoconf/manual/html_node/Autoconf-Macro-Index.html