Hi, in this programming related article I’m going to show you how to use automake, autoconf, libtool and other configuration and build environment tools to automate compilation of your un-organized .c files.  To be able to share your C source code with others in a way they can compile and make modifications to it you need these files properly set up.

Part 1 Motivation

Have you ever found yourself listing files in a old hack directory and got a list like this:

closeout.h  pathmax.h  sys2.h  system.h  true.c  version-etc.h

And no matter how hard you try you cant seem to get it compiling. Or, you have a list like this:

closeout.h  pathmax.h  sys2.h  system.h  true.c  version-etc.h Makefile

But it still won’t build using “make” because your set of available libraries is not compatible with what’s needed to build this package. Unfortunately the errors you get from trying are way too obscure to figure out what the hell went wrong.

If you do recognize this as a problem then please feel welcome to part two where we will discuss how to start making the foundation for a more general build environment.

Part 2 Start digging

So the directory listing above is parts of the GNU coreutils package from http://ftp.gnu.org/pub/gnu/coreutils/coreutils-5.0.tar.bz2. Which package I used is irrelevant, but what it does is when you run the command ./true it prints the word “true” on the terminal screen.

Before starting install the tools needed: apt-get install build-essential autoconf automake libtool


So with a bunch of source files and nothing else we shall start by using the tool called autoscan from the autoconf package.

From the description of autoscan manual we get this:

 autoscan - Generate a preliminary configure.in

 autoscan [OPTION] ... [SRCDIR]

 Examine  source  files in the directory tree rooted at SRCDIR, or the current directory if none is given.  Search the source
 files for common portability problems, check for incompleteness of 'configure.ac', and create a file 'configure.scan'  which
 is a preliminary 'configure.ac' for that package.

OK, so what this one does is it reads “.c” and “.h” files and looks for “#include” statements and it lists them in a file called configure.scan.

The content of configure.scan file after running autoscan was:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.


# Checks for programs.

# Checks for libraries.

# Checks for header files.
AC_CHECK_HEADERS([fcntl.h inttypes.h limits.h locale.h malloc.h memory.h stdint.h stdlib.h string.h strings.h sys/file.h sys/param.h sys/time.h unistd.h utime.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_CHECK_MEMBERS([struct stat.st_blksize])

# Checks for library functions.
AC_CHECK_FUNCS([atexit setlocale])


This file is the fundamental description of what source files we depend on  in this “package”.

What we want to do now is to rename it, from configure.scan to configure.ac.  There is one thing missing in “configure.ac“, it’s a line telling automake (comming to that later) to make its checks.

Edit the file configure.ac and add these two lines:


The file extension “.ac” means it’s a autoconf file, so let’s try autoconf, shall we?


The tool autoconf will in turn read the configure.ac in order to generate a configure script, ready to be used for Makefile generation later.

The configure script is a “/bin/sh script” that will check to see that all libraries needed for compiling are available and it will try to generate a “Makefile” specific to your Machine and OS type.

If you at some point make a change to the configure.ac you should run autoreconf instead of autoconf.

Now this was the configuration part, now let’s take a look at the “make part”.


Now we are going to do something which requires a little bit of manual work. We are going to create an automake file; they have the file extension “.am

Create a file called “Makefile.am” in this file we are going to describe what we actually want to get as output from compiling this package. In this example I want to be able to run “./true” so I’m going to try to write a Makefile.am which will make true.c the real “true” executable.

Here is what I wrote in my Makefile.am to make true.c the source of “true” the running binary.

true_SOURCES= true.c

The AUTOMAKE_OPTIONS is determining if the program has the standard set of arguments available, like –version or –help so that it can try them to verify that everything was successful after compiling is done.

If you would have some kind of dependency to some external library say for instance “curses“, then it should be LIBS= -lcurses

One really sweet thing coming up with automake is the fact that it knows what you have forgotten to do. If you have forgotten to add a “copying” license file or some other package-related file missing for the build scripts to work, it will add them for you.

automake --add-missing

Then run automake again to convert the Makefile.am to a Makefile.in which is used to define “make targets”.

A “make target“  is a goal of running make, such as installing a program globally or cleaning or just test compiling in a local folder.

So after running the previous steps “autoscan”,”rename configure.scan to configure.ac”, “edit configure.ac”,”autoconf”,”Create Makefile.am”, “automake –fix-missing”,”automake” we have a environment for building true.c, my file listing now looks like this:

aclocal.m4       closeout.h   config.h.in~    configure*    depcomp@     Makefile     missing@   sys2.h    version-etc.h
autom4te.cache/  config.h     config.log      configure.ac  INSTALL@     Makefile.am  pathmax.h  system.h
autoscan.log     config.h.in  config.status*  COPYING@      install-sh@  Makefile.in  stamp-h1   true.c

Now this is what the package should look like after downloading a tar.gz file from the web and extracting it.

This image is a metaphor for going from planning to building.

This image is a metaphor for going from planning to building.

Part 3 Trying, Failing, Trying, Building!

It looks good, so let’s see if it fits!


Let’s assume this fails, for any reason. Then you can go back to the “autoscan“/ “.ac“/”.am” stage and make your changes and try to re-generate.

Using these tools and methods can help you to port and repackage all kinds of projects in the GNU world.

That’s all for now, I hope you can learn to master the wonderful autotools! Kisses and hugs // Kugg

Tagged with:
Set your Twitter account name in your settings to use the TwitterBar Section.
Creeper MediaCreeper