Don't Fear the Autotools!
Scott GarmanPortland Linux User GroupDecember 1, 2011
AC_INIT([Scott Garman], [1.0], [[email protected]])
● 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