1. Don't Fear the Autotools!
Scott Garman
Portland Linux User Group
December 1, 2011

2. 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

3. 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

4. From a User's Perspective
● tar xvzf application-1.0.tar.gz
● cd application-1.0/
● ./configure
● make
● sudo make install

5. 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

6. 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

7. config.status
● Uses information from configure to perform
substitutions in *.in template files to generate
the output files:
configure config.log
config.h.in config.h
config.status
Makefile.in Makefile

8. 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!)

9. 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/

10. 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/

11. From a Developer's Perspective
● Autoconf:
configure.ac autoconf/autoreconf
configure config.log
config.h.in config.h
config.status
Makefile.in Makefile

12. From a Developer's Perspective
● Automake:
configure.ac autoconf/autoreconf
configure config.log
config.h.in config.h
config.status
Makefile.in Makefile
automake/autoreconf Makefile.am

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

14. 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

15. 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)

16. 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

17. 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/Auto
conf-Macro-Index.html