Your SlideShare is downloading. ×
Don't Fear the Autotools
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Don't Fear the Autotools


Published on

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Dont Fear the Autotools!Scott GarmanPortland Linux User GroupDecember 1, 2011
  • 2. AC_INIT([Scott Garman], [1.0], [])● Embedded Linux SW Engineer at Intel● Working on the Yocto Project (● I am not an Autotools fanboy; just a pragmatic user● I do not really know all that much about Autotools● Its 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 Users 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 config.status Makefile
  • 8.● Running configure tests can take a while● If youre installing many apps from source, youll 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 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 file to make use of it● Very handy when cross-compiling apps (since some tests compile small C programs, but those programs cant 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●
  • 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●
  • 11. From a Developers Perspective● Autoconf: autoconf/autoreconf configure config.log config.h config.status Makefile
  • 12. From a Developers Perspective● Automake: autoconf/autoreconf configure config.log config.h config.status Makefile automake/autoreconf
  • 13. Hello World Example● Lets 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 (; 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 Practitioners Guide to GNU Autoconf, Automake, and Libtool, by John Calcote. No Starch Press.● Autotools Tutorial by Alexandre Duret-Lutz:● GNU Coding Standards:● Filesystem Hierarchy Standard:● Autoconf Macro Definitions: conf-Macro-Index.html