Autotools

AUTOTOOLS : beyond the theory, some practical usage
AutotoolsAUTOTOOLS : beyond the theory, some practical usage
Thierry GAYET (EUROGICIEL)

PLAN
1. Autotools introduction
2. Mastering the build process
3. Quick GNU/Make reminder
4. The autotools process
5. Using the autoscan tool
6. The autogen.sh script
7. Using libtool7. Using libtool
8. The configure.{ac/in} template
9. The Makefile.am template
10.Using the library’s template
11.Using the application’s template
12.Many more usage ….
13.Conclusion

Autotools introduction
The goal of this topic is to know how to well works with the autotools in a cross-
compilation environement

History :
Historically, a shell configure script transformed a Makefile.in into a
Makefile
Autoconf 1 (1992): autoconf transformed a configure.in into a configure
file
The autotools process
Autoconf 2 (1994): added cross-compilation support, sub-directories,
hidden results, more tests, …
Automake (1994): automake transformed a Makefile.am into a Makefile
Libtool (1996): changed the Automake behavior

Here is the full power of the autotools in action that make build easier:

The Autotools are a set of scripts (automake, autoconf, aclocal, autoheader, libtools, … )
that use M4 macros.
Template make the component portable (not dependant from a specific build system)
Lot of built-in rules needed for transformations
(.c→.o, .c→.s, .o→binary, .c→.a, .c→.so, … )
Developers only write basic templates (configure.ac and makefile.am).
Well adapt to the cross-compilation
Templates make the makefiles independant of an architecture
6
Templates make the makefiles independant of an architecture
Final makefile will be written as standard GNU/make.
Lot of built-in features:
• Launch the build: make
• Clean the environment: make clean or make distclean
• Install the build into the stagingdir: make DESTDIR=<PATH> install
• Uninstall the build from the stagingdir make DESTDIR=<PATH> uninstall
• Generate an archive of the current build: make dist
• Many other useful targets…

Autotools is a collection of OSS tools :
GNU Automake is a tool for automatically generating `Makefile.in' files compliant
with the GNU Coding Standards.
http://www.gnu.org/software/automake/
GNU Autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. These
scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a
package from a template file that lists the operating system features that the package can use, in the form of M4 macro calls.
Producing configuration scripts using Autoconf requires GNU M4. You should install GNU M4 (at least version 1.4.6, although 1.4.13 or later is
recommended) before configuring Autoconf, so that Autoconf's configure script can find it. The configuration scripts produced by Autoconf are self-
contained, so their users do not need to have Autoconf (or GNU M4).
http://www.gnu.org/software/autoconf/
GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface.
http://www.gnu.org/software/libtool/
pkg-config is a helper tool used when compiling applications and libraries. It helps you insert the correct compiler options on the command line so an
application can use gcc -o test test.c `pkg-config --libs --cflags glib-2.0` for instance, rather than hard-coding values on where to find glib (or other
libraries). It is language-agnostic, so it can be used for defining the location of documentation tools, for instance.
http://www.freedesktop.org/wiki/Software/pkg-config
GNU M4 is an implementation of the traditional Unix macro processor. It is mostly SVR4 compatible although it has some extensions (for example,
handling more than 9 positional parameters to macros). GNU M4 also has built-in functions for including files, running shell commands, doing
arithmetic, etc.
GNU M4 is a macro processor in the sense that it copies its input to the output expanding macros as it goes. Macros are either builtin or user-defined
and can take any number of arguments. Besides just doing macro expansion, m4 has builtin functions for including named files, running UNIX
commands, doing integer arithmetic, manipulating text in various ways, recursion etc... m4 can be used either as a front-end to a compiler or as a
macro processor in its own right.
http://www.gnu.org/software/m4/
Autogen.sh (a.k.a. buildconf) provides automatic build system preparation and is generally very useful to projects that use the GNU build system (i.e.
the GNU autotools: autoconf, automake, and libtool).
http://buildconf.brlcad.org/
A toolchain (GNU or other) that include binutils.

The GNU Binutils are a collection of binary tools. The main ones are:
* ld - the GNU linker.
* as - the GNU assembler.
But they also include:
* addr2line - Converts addresses into filenames and line numbers.
* ar - A utility for creating, modifying and extracting from archives.
* gprof - Displays profiling information.
* nm - Lists symbols from object files.
* objcopy - Copies and translates object files.
* objcopy - Copies and translates object files.
* objdump - Displays information from object files.
* ranlib - Generates an index to the contents of an archive.
* readelf - Displays information from any ELF format object file.
* size - Lists the section sizes of an object or archive file.
* strings - Lists printable strings from files.
* strip - Discards symbols.
For a cross-compilation usage a prefix is added before the name of the binutils (sh4-linux-ar, sh4-
linux-nm, sh4-linux-strip, .... )
As well as for the makefile, autotools can be used for the cross-compiling but it can be also used for
generating pdf, html, latex, … in other words, this is a mechanism for managing file transformations
including dependencies.

SDK (stagingdir) :
Temporary rootfs dedicated to
the target arch
Toolchain :
• gcc
• headers
• host tools
• …
(Local rootfs) Intermediate installation :
make DESTDIR=<STAGINGDIR> install
Used for compilation (headers) : -I<headerpath>
9
For each embedded device, another separated SDK is required.
Le stagindir peut inclure les hosttools pour n’avoir qu’une zone de dev.
Configuration Mngt
(SVN, GIT, CC, … )
Used for compilation (headers) : -I<headerpath>
and links (libraries) : -L<libpath> -l<libname>
Real rootfs for
the
embedded target Real
embedded
target
Firmwares
Flashing
NFS
BOOT
Final installation :
make DESTDIR=<ROOTFSDIR> install

Focus on the staging_dir (aka SDK environment) :
/usr /lib libraries (.a/.so/.la)
pkgconfig/ pkg-config
metadata (.pc)
STAGING_DIR
/include/<comp_namespace>/ header / public API (.h)
STAGING_DIR
PREFIX
(eg: /usr, /local/usr)
The staging directory is used as an intermediate filesystem for development purpose.
All packages should install their build into (make DESTDIR=<STAGINGDIR> install).
This is a reference between packages that need to compile and link with (in other words
that have depencencies with external packages).
Example: ./configure--prefix=/usr …

/usr /lib
/include/<comp_namespace>/
pkgconfig/
SDK
/local/staging
Installation de :
- liba.a + liba.so + liba.la dans /usr/lib
- liba.pc dans /usr/lib/pkgconfig
Dependency with A through
PKG_CHECK_MODULE(A)
B
Installation de :
- libb.a + libb.so + libb.la dans /usr/lib
- libb.pc dans /usr/lib/pkgconfig
Example dependencies
bewteen two
components A and B
# Environment setting
SDK=/local/staging
PREFIX=/usr
# Configuration
./configure --prefix=$(PREFIX)
# Compiling
make
# Installation
make DESTDIR=$(SDK) install
- liba.pc dans /usr/lib/pkgconfig
- a.h dans /usr/include
# Environment setting
SDK=/local/staging
PKG_CONFIG_PATH=$(SDK)/lib/pkgconfig
PREFIX=/usr
# Configuration
./configure --prefix=$(PREFIX)
# Va récupérer B_CFLAGS: -I$(SDK)/$(PREFIX)/include
# B_LDFLAGS: -L$(SDK)/$(PREFIX)/lib -la
# Compiling
make
# Installation
make DESTDIR=$(SDK) install
A
B
- libb.pc dans /usr/lib/pkgconfig
- b.h dans /usr/include
The A package don’t have any dependencies except the libc.

xxx.pc.in
For each package a developper will ONLY have to managed some templates : Makefile.am + configure.ac
• provided by the developers
• stored in repository ( CC UCM)
config.cache
config.log
autogen.sh
autoconf
The autotools process in detail :
Makefile.am
configure.ac aclocal.m4
configure
config.h.in
Makefile.in
config.h
Makefile
xxx.pc
automake
autoheader
aclocal
USER VIEWDEV. VIEW

Initial preparation :
./autogen.sh
Configuration :
./configure --prefix=/usr
Compiling :
Compiling :
make
Installation :
make DESTDIR=«stagingdir» install

Mastering the build process
The goal of this topic is to know how the build process works.

The GNU Compiler Collection (GCC) :
is a compiler system produced by the GNU Project
is supporting various programming languages
is a key component of the GNU toolchain
has been adopted as the standard compiler by most other modern Unix-like computer
operating systems, including Linux, the BSD family and Mac OS X
has been ported to a wide variety of processor architectures
is widely deployed as a tool in commercial, proprietary and closed source software
development environments
is also available for most embedded platforms, for example Symbian (called gcce), AMCC
and Freescale Power Architecture-based chipsand Freescale Power Architecture-based chips
can target a wide variety of platforms, including videogame consoles such as the PlayStation
2 and Dreamcast. Several companies make a business out of supplying and supporting GCC
ports to various platforms, and chip manufacturers today consider a GCC port almost
essential to the success of an architecture.
Originally named the GNU C Compiler, because it only handled the C programming language,
GCC 1.0 was released in 1987, and the compiler was extended to compile C++ in December of that
year. Front ends were later developed for Fortran, Pascal, Objective-C, Java, and Ada, among others.
The Free Software Foundation (FSF) distributes GCC under the GNU General Public License
(GNU GPL). GCC has played an important role in the growth of free software, as both a tool and an
example.
http://gcc.gnu.org

Summary :
Dynamic library .so
Static library .a
Objetcs .o
Source code
.c / .cpp
Headers
.h
Preprocessing
gcc -E
Linking
ld
Compiling
gcc -c
.o
Output
ELF
Object
Assembling
as
gcc --verbose
provides lot of information for each step.

C preprocessing:
• Lexical preprocessors.
• Operate on the source text.
• Prior to any parsing by performing simple substitution of tokenized
character sequences.
• Typically perform macro substitutions by inlining and templates, textual
inclusion of other files, and conditional compilation or inclusion.
inclusion of other files, and conditional compilation or inclusion.
• Take lines beginning with '#' as directives
This is possible to stop the Compiler at this specific step. The stdout will
generate the result of the C preprocessing. This command is equivalent to a
build command (compiling or link) with no output file expected:
$ gcc -E file.c
http://www.crasseux.com/books/ctutorial/Preprocessor-directives.html

Assembler :
If the –S parameter is given to gcc, it stops after the compilation stage; it does
not assemble. The output is in the form of an assembler code file for each non-
assembler input file specified.
By default, the assembler file name for a source file is made by replacing the suffix
.c, .i, etc., with .s
Input files that do not require compilation are ignored.
Example for getting the assembly code of a .c source code:
$ gcc -S file.c
http://homepage.fudan.edu.cn/~euler/gcc_asm/

Compiling : the compiler’s frontend :
• Parses the source code through a lexical/semantic analyzer (such as GNU/flex) .
• Builds an internal representation of the program.
• In a first step it generates non-optimized intermediate code.
• In a second step it generates optimized intermediate code (if required).
• The intermediate code is adapted to the target architecture.
Example for generating an intermediate object:
$ gcc -c file.c -o file.o
$ file file.o
file.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
GCC = GNU Compiler collection
GCC
C JAVA Fortran PascalASM...

Linking : the compiler’s backend
• Generates assembly code for the final output.
• Generates ELF object (replace the old a.out one).
• Uses ld through the gcc.
• Can make:
Binary: adds a main entry to the intermediate code.
Dynamic library: if the -shared parameter has been given (cannot be
runable except for the libc).
runable except for the libc).
Direct usage with the ld linker : $ ld -o mybinary /lib/crt0.o file.o –lc
crt0 (or crt0.o, gcrt0.o, mcrt0.o) is a set of execution start-up routines (usually part of
the C standard library) that are platform dependent, and is required in order to compile
using GCC and other GNU tools. crt stands for "C runtime".
-e entry
Use entry as the explicit symbol for beginning execution of the program, rather than the
default entry point (main). If there is no symbol named entry, the linker will try to parse
entry as a number, and use that as the entry address (the number will be interpreted in
base 10; you may use a leading 0x for base 16, or a leading 0 for base 8).

GNU tools from the toolchain are set for an embedded usage :
--sysroot=staging directory
Use dir as the logical root directory for headers and libraries. For example, if the compiler would normally search for headers in
/usr/include and libraries in /usr/lib, it will instead search dir/usr/include and dir/usr/lib.
If you use both this option and the -isysroot option, then the --sysroot option will apply to libraries, but the -isysroot option will apply to
header files.
The GNU linker (beginning with version 2.16) has the necessary support for this option. If your linker does not support this option, the
header file aspect of --sysroot will still work, but the library aspect will not.
Usually te environment is defined like this :Usually te environment is defined like this :
export STAGING_DIR=<PATH TO THE STAGING DIRECTORY>
export PREFIX=«i686-cm-linux-»
export TOOLCHAIN_DIR=<PATH TO THE TOOLCHAIN>
export CC=$(PREFIX)gcc --sysroot=$(STAGING_DIR)
export LD=$(PREFIX)ls --sysroot=$(STAGING_DIR)
export GCC=$(PREFIX)gcc --sysroot=$(STAGING_DIR)
export CXX=$(PREFIX)gcc --sysroot=$(STAGING_DIR)
export GDB="$(STAGING_DIR)/bin/$(PREFIX)gdb"
export RANLIB="$(TOOLCHAIN_DIR)/bin/$(PREFIX)ranlib"
export STRIP="$(TOOLCHAIN_DIR)/bin/$(PREFIX)strip"
export OBJCOPY="$(TOOLCHAIN_DIR)/bin/$(PREFIX)objcopy"
export AR="$(TOOLCHAIN_DIR)/bin/$(PREFIX)ar"
export AS="$(TOOLCHAIN_DIR)/bin/$(PREFIX)as"
export LD="$(TOOLCHAIN_DIR)/bin/$(PREFIX)ld"
export NM="$(TOOLCHAIN_DIR)/bin/$(PREFIX)nm”
etc …

BUILD PORCESS LAB
BUILD PORCESS LAB

The main goal of this lab is to know how is working the
GNU/
Using the helloworld.c source code try several parameters
{--verbose/-E/-S}:
gcc --verbose
gcc -c helloworld.c
gcc -c helloworld.c -o helloworld.o
gcc -E helloworld.c
gcc -S helloworld.c
…

Quick GNU/make reminder
The goal of this topic is to know how works common GNU/make

The final files generated are gnu/make based.
Most Makefile.am can be extend with gnu/make features that’s why this is
important to know how makefiles are made.
We will remain some basic makefile usage.

The make program gets its dependency "graph" from a text file called makefile or
Makefile which resides in the same directory as the source files. Make checks the
modification times of the files, and whenever a file becomes "newer" than something
that depends on it, (in other words, modified) it runs the compiler accordingly.
26
Project1 is a target and the name of the final binary. Its dependencies are the three
objects data.o, main.o and io.o. Each one have in teir turn their own dependencies that
make will resolve one by one.
If you edit io.c, it becomes "newer" than io.o, meaning that make must run gcc -c io.c to
create a new io.o, then run gcc data.o main.o io.o -o project1 for project1.

Each dependency shown in the graph is circled with a corresponding color in the
Makefile, and each uses the following format:
target : source file(s)
command (must be preceded by a tab)
A target given in the Makefile is a file which will be created or updated when any of its
source files are modified. The command(s) given in the subsequent line(s) (which must be
preceded by a tab character) are executed in order to create the target file.
27
For more information : http://www.gnu.org/doc/doc.html

By default make will look for a “Makefile” file. We can specify another one through the –f
parameter :
$ make –f myMakefile will use myMakefile instead
$ make –C /myProject will use the makefile present in /myProject directory
If no Makefile is found, the make program will display:
make: *** No targets specified and no makefile found. Stop.
Make is compatible with native code and with cross-compilation. Adding specific rules for
using a toolchain is very easy:
28
CC=$(PREFIX)-gcc
.c.o:
$(CC) –c $(CFLAG) –o $@ $<
Make can get setting from environment variables or parameters:
export TOOLCHAIN_BIN=<PATH_TOOLCHAIN>/bin
export PREFIX=sh4-linux
or
make ARCH=sh CROSS_COMPILE=sh4-linux
then launch the “make” command.
Command used for cross-compiling the
GNU/Linux kernel.

In addition to those macros which you can create yourself, there are a few macros which
are used internally by the make program.
Here are some of those, listed below:
CC Contains the current C compiler. Defaults to gcc.
CFLAGS Special options which are added to the built-in C rule.
$@ Full name of the current target.
$? A list of files for current dependency which are out-of-date.
You can also manipulate the way these macros are evaluated, as follow, assuming that OBJS =
data.o io.o main.o, using $(OBJS:.o=.c) within the Makefile substitutes .o at the end with .c, giving
you the following result: data.c io.c main.c
For debugging a Makefile : $ make -d
$? A list of files for current dependency which are out-of-date.
$< The source file of the current (single) dependency.
LDFLAGS Special options which are added to the link.

Compilation and link:
Uses “make” from the command line (it will call the default target such as “all”)
Will look for the current Makefile or another file given with -f)
Does not include lot of default rules and everything should be manually implemented
Installation:
Uses “make install” for the command line
Not in standard … should be done by your own
The install/cp command can be used
Input file
.c
Several targets used by gnu/makefile :
30
The install/cp command can be used
Cleaning:
Uses “make clean” from the command line
Remove temporally and intermediate objects generate
during the build process
Archive/delivery:
Uses “make delivery” from the command line
Not in standard … should be also done by your own
The tar.gz/tar.bz2/.7z/zip/... compression algorithms can be used
Transformation
Output file
.c
.o

With GNU/Makefiles :
No target is buildin ; everything should be written from scratch
each time ;
Doesn’t use generic templates for binaries, libraries, … ;
Cross-compilation support should be manualy specified ;
Pkg-config can be used (not by M4 macros) ;
Can make ugly Makefile ;
Can make ugly Makefile ;
Makefile are often more static than dynamic
Everything done by gnu Makefile is automatically
natively supported by the Autotools ☺☺☺☺ !
Everything done by gnu Makefile is automatically
natively supported by the Autotools ☺☺☺☺ !

Other make engine exists:
o cmake (http://www.cmake.org/)
o qmake (http://doc.qt.nokia.com/4.4/qmake-manual.html)
o and so on…
For more information about the GNU/make:
For more information about the GNU/make:
http://oreilly.com/catalog/make3/book/index.csp
http://www.wanderinghorse.net/computing/make/book/ManagingProjectsWithG
NUMake-3.1.3.pdf
http://notendur.hi.is/~jonasson/software/make-book/
http://www.gnu.org/software/make/manual/make.pdf
http://en.wikipedia.org/wiki/Make_(software)#Modern_versions
http://ecee.colorado.edu/~mcclurel/gnu_make_overview.pdf
http://static.maemo.org/static/d/dcacc028fda611dd9062b3dd54505f765f76_gnu_
make_and_makefiles.pdf

GNU/MAKE LAB
GNU/MAKE LAB

The main goal of the lab is to write a makefile with several targets:
The project have three source code: data.c, main.c and io.c
The make file should support the following targets:
Compilation: make (aka make all)
Cleaning old objects: make clean
Create tarball: make dist
Create an installer: make DESTDIR=«PATH» install
Create an uninstaller: make DESTDIR=«PATH» uninstall

So, if we check the several Makefiles written,
no one will be identical,
that’s mean there is no uniformisation/no standard.
That what the autotools provide.
So, if we check the several Makefiles written,
no one will be identical,
that’s mean there is no uniformisation/no standard.
That what the autotools provide.

The goal of this topic is to know how works the templates are written.

Developers, will work only on the following
templates:
configure.ac
Makefile.am
<component>.pc.in
Only those files will be saved in the repository.
STEP 0 : introspection with existing source
code. Will generate a configure.san (to be
renamed into a configure.ac)
STEP 2 : this is what the end user will work
with:
./configure …
make
make install
STEP 1 : this is an intermediate step done
by the autogen.sh script. This should be
done each time the templates are updated.

./autogen.sh
./configure --prefix …
make dist
make or make –j7
make html
This target generates a
documentation from the
latest public API (headers).
This target generates a
tarball..
Generates the final files (Makefile, config.h, … )
make DESTDIR=<PATH> install make check
This target launches the unitary tests using the Google
test/mock and provides junit.xml report per unit test.
If gcov has been set, it will generate some information
that will be analysed by lcov.
--enable-test should be set to the configure script
latest public API (headers).
This target generates the
(cross)compilation
and the link of the component.
This target intalls the files generated
during the build process.
make DESTDIR=<PATH> uninstall
This target unintalls the files already installed by a
previous install process.

working with the autotools means for a developer to manage templates and
potfiles :
Makefile.am : used to define what should be build and how
using generic templates.
configure.ac : used to define an autotools project. It can include
<component>.*.in : used to associate some metadata
(this is used by *.pc.in used for managing
dependencies or config files).
Only those files have to be managed by the developers.
No more files need to be stored in repository except if there are filled
(README, LICENCE, … ).

STEP #1 : autogen.sh
The autogen.sh is a generic script used to prepare an autotool project for end users.
Its goal is to check the environment need for the autotools scripts and binaries.
This script need to be launched each time a template have been modified.
It will generate several files:
o a configure script from the configure.ac
a Makefile.in form the Makefile.amo a Makefile.in form the Makefile.am
o a config.h.in if expected
Roadmap : configure.acconfigure.acconfigure.acconfigure.ac ---
|
| ------> autoconfautoconfautoconfautoconf* -----> configureconfigureconfigureconfigure
[aclocal.m4] --+--- |
| -----> autoheaderautoheaderautoheaderautoheader* --> [[[[config.h.inconfig.h.inconfig.h.inconfig.h.in]]]]
|
[acsite.m4] -----
Makefile.amMakefile.amMakefile.amMakefile.am -------------------------------> Makefile.inMakefile.inMakefile.inMakefile.in

STEP #2 : configuration, compilation and installation
This is the end user view.
This step must start by the launch of the configure script in order to generate a final
Makefile:
./configure --prefix=/usr …
Then, this is possible to use the several target from the Makefile:
Targets Descriptions
make
make –j7
make all
Build programs, libraries, documentation, etc …
make install Install what needs to be installed, copying the files from the package's tree to system-wide directories.
make install-strip Same as make install, then strip debugging symbols. Some users like to trade space for useful bug reports...
make uninstall The opposite of make install: erase the installed files. (This needs to be run from the same build tree that was
installed.)
make clean Erase from the build tree the files built by make all.
make distclean Additionally erase anything ./configure created.
make check Run the test suite, if any.
make installcheck Check the installed programs or libraries, if supported.
make dist Recreate package-version.tar.gz from all the source files.
and so on…

Global summary :
STEP 0 : Reverse from the existent source code:
your source files --> autoscanautoscanautoscanautoscan****--> [[[[configure.scanconfigure.scanconfigure.scanconfigure.scan]]]] --> configure.acconfigure.acconfigure.acconfigure.ac
STEP 1 : preparing a software package :
configure.acconfigure.acconfigure.acconfigure.ac ---
|
| ------> autoconfautoconfautoconfautoconf* -----> configureconfigureconfigureconfigure
[aclocal.m4] --+--- |
| -----> autoheaderautoheaderautoheaderautoheader* --> [[[[config.h.inconfig.h.inconfig.h.inconfig.h.in]]]]
|
Make by the autogen.sh script
|
[acsite.m4] -----
Makefile.amMakefile.amMakefile.amMakefile.am -------------------------------> Makefile.inMakefile.inMakefile.inMakefile.in
STEP 2 : configure/compile/install/… the package:
.-------------> [config.cacheconfig.cacheconfig.cacheconfig.cache]]]]
|
configureconfigureconfigureconfigure* ----------------+-------------> [config.logconfig.logconfig.logconfig.log]
|
|
[[[[config.h.inconfig.h.inconfig.h.inconfig.h.in]]]] -- | ----> [[[[config.hconfig.hconfig.hconfig.h]]]] -----
| v | |
|------ config.statusconfig.statusconfig.statusconfig.status**** ---- | | --> makemakemakemake*
| | |
Makefile.inMakefile.inMakefile.inMakefile.in --- ----> MakefileMakefileMakefileMakefile ---
| |
[<comp>.pc.in ]--- -----> [<[<[<[<comp.pccomp.pccomp.pccomp.pc>]>]>]>]
Make by the configure script

We are seeing the existing files before to launch autoconf :
$ cat configure.ac
AC_INIT
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
$ cat Makefile.in
prefix = @prefix@
datadir = @datadir@
We are launching the autoconf (or autoreconf):
Thus, variables between areobases such as
@prefix@ will be replace by the value
given to the configure script:
$ autoconf
We are launching the configuration step:
$ configure –prefix=/usr/local
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING:
Makefile.in seems to ignore the --datarootdir setting
We are consulting the files after the configuring step:
$ cat Makefile
prefix = /usr/local
datadir = ${prefix}/share
@prefix@ /usr/local

Debugging via autom4te:
At times, it is desirable to see what was happening inside m4, to see why output was not matching expectations. However, post-
processing done by autom4te means that directly using the m4 builtin m4_traceon is likely to interfere with operation. Also, frequent
diversion changes and the concept of forbidden tokens make it difficult to use m4_defn to generate inline comments in the final output.
There are a couple of tools to help with this. One is the use of the --trace option provided by autom4te (as well as each of the programs
that wrap autom4te, such as autoconf), in order to inspect when a macro is called and with which arguments. For example, when this
paragraph was written, the autoconf version could be found by:
$ autoconf --trace=AC_INIT
configure.ac:23:AC_INIT:GNU Autoconf:2.63b.95-3963:bug-autoconf@gnu.org
$ autoconf --trace='AC_INIT:version is $2‘
version is 2.63b.95-3963version is 2.63b.95-3963
Another trick is to print out the expansion of various m4 expressions to standard error or to an independent file, with no further m4
expansion, and without interfering with diversion changes or the post-processing done to standard output. m4_errprintn shows a given
expression on standard error. For example, if you want to see the expansion of an autoconf primitive or of one of your autoconf macros,
you can do it like this:
$ cat <<EOF > configure.ac
AC_INIT
m4_errprintn([The definition of AC_DEFINE_UNQUOTED:])
m4_errprintn(m4_defn([AC_DEFINE_UNQUOTED]))
AC_OUTPUT
EOF
$ autoconf
error-->The definition of AC_DEFINE_UNQUOTED:
error-->_AC_DEFINE_Q([], $@)

Template #1: basic project
makefile.am
configure.ac
autogen.sh
Template for the project
Template for the Makefile
Generate the final files
45 06/17/10
src/
include/
If you prefer to generate intermediate objects in a obj/ directory (or src/), you can move the
makefile.am to the chosen directory). For information, all the intermediate objects are
generated in the same directory than the Makefile.am template.
Contains all the source code
Contains all the headers
The configure.in is equivalent to the configure.ac

Template #2 : project with subdirectories
makefile.am
configure.ac
src/
include/
autogen.sh
Template for the project
Main template for the Makefile
Generate the final files
include/module1/
module2/
makefile.am Sub-template1 for the
Makefile
src/
include/
makefile.am Sub-template2 for the
Makefile
Another project example with subdirectories.

• The essential files:
The smallest project requires you provide only two files:
CONFIGURE.AC : an input file to autoconf that provides the macro invocations and shell code fragments
autoconf uses to build a configure script.
MAKEFILE.AM: an input file to automake that specifies a projects build requirements: what needs to be built,
and where it goes when installed.
The GNU Autotools will generate the rest of the files needed to build the project.
• The Directory Structure:
Before writing any code for a new project you need to decide on the directory structure the project will use ;
The top-level directory is used for configuration files, such as configure.in, and other sundry files like ChangeLog,
COPY (a copy of the project license) and README ;
Any unique library should have its own subdirectory containing all headers and sources, a Makefile.am, and any
other library specific files ;
The headers and sources for the main application should be in another subdirectory, typically called src ;
Other directories can include: config for intermediate files, doc for the project documentation and test for the
project self-test suite ;
The following steps will take you through creating and building the HelloWorld project. The top-level directory for
HelloWorld is <tests/project>. You will find the project's headers and sources in the src subdirectory. There are three
files: helloworld.cc, helloworld.h and main.cc ;

Using an Autotools project at a glance
Then, using this Autotools project is simple:
1. Generate the final files from the autotools templates: $ ./autogen.sh
makefile.am Makefile.in
configure.ac configure
(it also generate config.h.in if used)
2. Launch the configure script with parameters:
$ ./configure -–prefix=/usr
-–enable-debug
3. Launch the compilation: $ make
4. Install the files: $ make DESTDIR=${stagingdir} install
5. Launch the unitary tests: $ make check
6. Generate the documentation: $ make html
All the intermediate files have a .in extension ; they will be used as input by the configure
script for generating all the final files.
Thus, by providing *.pc.in files we are providing intermediate file ready for the update
process…

AUTOTOOLS LAB
AUTOTOOLS LAB

The goal of this lab if to use an hello world autotools project.
Experiment the several steps :
Preparation: ./autogen.sh
See the files before and after.
Configuration: ./configure –prefix=/usr
Read the config.log that detail the configuration step ; this is a good way
to debug a configure script.
Compilation: make
Installation: make DESTDIR=pwd install
Delivery: make dist

Using the autoscan tool
The goal of this topic is to know how to use the autoscan tool

STEP #0 : autoscan
The easiest way to create a (mostly) complete configure.ac file is to run the
autoscan utility, which is part of the autoconf package.
This utility examines the contents of a project directory and generates the basis for
a configure.ac file (which autoscan names configure.scan) using existing makefiles
and source files.
The autoscan utility examines the project directory hierarchy and creates two files
called configure.scan and autoscan.log.called configure.scan and autoscan.log.
The project may or may not already be instrumented for Autotools ; it doesn’t really
matter, because autoscan is decidedly non-destructive. It will never alter any
existing files in a project.
your source files autoscanautoscanautoscanautoscan**** configure.scanconfigure.scanconfigure.scanconfigure.scan configure.acconfigure.acconfigure.acconfigure.ac

After the launch of the autoscan tool, two files should appear in the current directory:
autoscan.log
configure.scan should be renamed into a configure.ac file afterward
As we see, the contents of the generated configure.scan is similar to our hand-crafted
template:
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
First example with an empty directory:
AC_PREREQ(2.56)
AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
# Checks for programs.
# Checks for libraries.
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_OUTPUT
As the name autoscan implies, you can guess that it can do other things as well, not only
create empty configure.ac templates.

Second example with two existing files in the project:
A header sleep.h :
#include <stdio.h>
#include <unistd.h> /* Needed for sleep() */
A source code sleep.c :
#include "sleep.h"
#define SECONDS_TO_SLEEP 3
int
int
main()
{
unsigned int sleep_left = 0;
/* sleep() for SECONDS_TO_SLEEP seconds, then print a message. */
sleep(SECONDS_TO_SLEEP);
printf("I woke up after %d seconds.n", SECONDS_TO_SLEEP);
return 0;
}

# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ(2.56)
AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
AC_CONFIG_SRCDIR([sleep.c]) some file that is in the package's source directory.
AC_CONFIG_HEADER([config.h]) containing C preprocessor #define statements.
# Checks for programs.
AC_PROG_CC determine the C compiler to use.
That will automaticaly generate the following configure.scan script:
# Checks for header files.
AC_CHECK_HEADERS([unistd.h]) check for existing header file(s) (in our case only one, unistd.h).
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_OUTPUT
To get a very basic, but working input file to autoconf, rename configure.scan to
configure.ac: mv configure.scan configure.ac
Then update the AC_INIT macro, and add the AC_COPYRIGHT macro.

AUTOSCAN LAB
AUTOSCAN LAB

The main goal for this lab is to go into a directory where is
existing source code ;
Launch the autoscan command: ./autoscan
View the configure.scan generated.

The autogen.sh script
The goal of this topic is to know how works the autogen.sh script

The autogen.sh script is used for converting all the templates (configure.ac, Makefile.am, …) in
final files (Makefile, configure, …) needed for a common Autotools usage.
Thus, The autogen.sh script (a.k.a. buildconf) provides automatic build system preparation and is
generally very useful to projects that use the GNU build system (i.e. the GNU Autotools: autoconf,
automake, and libtool). It is a POSIX shell script that is used for preparing a build system for
compilation, verifying versions, ensuring necessary functionality, and overcoming many common
build preparation issues.
Official web site : http://buildconf.brlcad.org/Official web site : http://buildconf.brlcad.org/
Licence : BSD
Latest stable release : 23.12.2009
http://downloads.sourceforge.net/project/buildconf/autogen/2009.12.23/buildconf.2009.12.23.tar.gz?u
se_mirror=freefr&ts=1278845776
This script is standalone, its usage is mainly limited to a call in the autotools directory :
$ ./autogen.sh
Another way is to use the following command: autoreconf -i –force
(This is what the script do in background)

first, we need to generate the required output files from the two input files configure.in and Makefile.am. First we need to
collect all the macro invocations in configure.in that Autoconf will need to build the configure script. This is done with the
following command:
$ aclocal
This generates the file aclocal.m4 and adds it to the current directory. Next, run autoconf:
$ autoconf
After running autoconf you will find the configure script in the current directory. It's important to run aclocal first because
Before the autoconf script some bootstrap command was used:
After running autoconf you will find the configure script in the current directory. It's important to run aclocal first because
automake relies on the contents on configure.in and aclocal.m4.
There are a few files that the GNU standard says must be present in the top-level directory, and if not found Automake will
report an error. Enter the following command to create these files:
$ touch AUTHORS NEWS README ChangeLog
Now we can run automake to create Makefile.in. The –add-missing argument copies some boilerplate files from your
Automake installation into the current directory.
$ automake --add-missing
By now, the contents of the directory should be looking a lot like the top-level directory of a GNU package you may have
installed before:
aclocal.m4 autom4te.cache config.h.in configure.in depcomp install-sh Makefile.in mkinstalldirs README AUTHORS
ChangeLog configure COPYING INSTALL Makefile.am missing NEWS src

What the autogen.sh really do :
It tranforms the template into intermediate files:
Original file Final file
configure.ac/in configure
Makefile.am Makefile.in
Config.h.in (if expected)
Those files will complete the other files (component.pc.in), in order to be
ready for the configure script.
Note : configure.ac is by far the preferred naming for autoconf >= 2.50 while
configure.in is what was used by autoconf ⇐ 2.13 and was kept for *cough*
backward compatibility *cough*…

Long name Short
name
Description Default
--help -h Help on autogen.sh usage No
--verbose -v Verbose progress output No
--quiet -q Quiet suppressed progress output Yes
--download -d Download the latest config.guess from gnulib No
--version Only perform GNU Build System version checks No
Parameters used to control the autogen.sh script :
There is two controversal parameters with the --quiet and --verbose that can be set in the same
$ ./autogen.sh –version
Preparing the toe build system...please wait
Found GNU Autoconf version 2.67
Found GNU Automake version 1.11.1
Found GNU Libtool version 2.2.6b
autogen.sh build preparation script by Christopher Sean Morrison
+ config.guess download patch by Sebastian Pipping (2008-12-03)
revised 3-clause BSD-style license, copyright (c) 2005-2009
script version 20090301, ISO/IEC 9945 POSIX shell script
---
Version requested. No preparation or configuration will be performed.
Check of the autotools components version:
There is two controversal parameters with the --quiet and --verbose that can be set in the same
time!! Indeed, the autogen.sh script will follow the last one provided at the launch.
Identical as :
./autoconf --version
./automake –version
./libtool --version

$ ./autogen.sh –help
Usage: ./autogen.sh [-h|--help] [-v|--verbose] [-q|--quiet] [-d|--download] [--version]
--help Help on autogen.sh usage
--verbose Verbose progress output
--quiet Quiet suppressed progress output
--download Download the latest config.guess from gnulib
--version Only perform GNU Build System version checks
Description: This script will validate that minimum versions of the
GNU Build System tools are installed and then run autoreconf for you.
Autogen.sh usage can be obtain with the command line:
GNU Build System tools are installed and then run autoreconf for you.
Should autoreconf fail, manual preparation steps will be run
potentially accounting for several common preparation issues. The
AUTORECONF, AUTOCONF, AUTOMAKE, LIBTOOLIZE, ACLOCAL,
AUTOHEADER,
PROJECT, & CONFIGURE environment variables and corresponding _OPTIONS
variables (e.g. AUTORECONF_OPTIONS) may be used to override the
default automatic detection behavior.
autogen.sh build preparation script by Christopher Sean Morrison
+ config.guess download patch by Sebastian Pipping (2008-12-03)
revised 3-clause BSD-style license, copyright (c) 2005-2009
script version 20090301, ISO/IEC 9945 POSIX shell script
---
Help was requested. No preparation or configuration will be performed.

$ ./autogen.sh
Automatically preparing build ... done
The toe build system is now prepared. To build here, run:
./configure
make
Silent launch (default):
$ ./autogen.sh –verbose
Verbose output enabled
Found a configure template: ./configure.ac
Checking autoreconf version: autoreconf --version
Checking autoconf version: autoconf --version
Checking if 2.67.0 is greater than 2.52.0
Checking automake version: automake --version
Checking libtoolize version: libtoolize --version
Checking aclocal version: aclocal --version
Checking autoheader version: autoheader --version
Checking whether to only output version information
Backing up COPYING in /home/gayetth/workspace/TOE
cp -p COPYING COPYING.25605.protect_from_automake.backup
Backing up INSTALL in /home/gayetth/workspace/TOE
cp -p INSTALL INSTALL.25605.protect_from_automake.backup
Found an autom4te.cache directory, deleting it
rm -rf autom4te.cache
 Verbose launch
make rm -rf autom4te.cache
mv -f "./config.guess" "./config.guess.backup"
mv -f "./config.sub" "./config.sub.backup"
mv -f "./ltmain.sh" "./ltmain.sh.backup"
Automatically preparing build ... autoreconf -i -f
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
rm -f COPYING.25605.protect_from_automake.backup
Restoring INSTALL from backup (automake -f likely clobbered it)
rm -f INSTALL
mv INSTALL.25605.protect_from_automake.backup INSTALL
rm -f INSTALL.25605.protect_from_automake.backup
rm -f "./config.guess.backup"
rm -f "./config.sub.backup"
rm -f "./ltmain.sh.backup"
done
The toe build system is now prepared. To build here, run:
./configure
make
rm -f "./config.guess.backup"
rm -f "./config.sub.backup"
rm -f "./ltmain.sh.backup"

Name Type Description
AUTOCONF Boolean Enable/disable the autotconf launch
AUTOCONF_VERSION String Specify a specific version for the autoconf package
AUTOCONF_OPTIONS String Specify the parameters to provide to the autoconf tool
AUTORECONF Boolean Enable/disable the autotconf launch
AUTORECONF_OPTIONS String Specify the parameters to provide to the autoreconf tool
AUTOMAKE Boolean Enable/disable the automake launch
AUTOMAKE_VERSION String Specify a specific version for the automake package
AUTOMAKE_OPTIONS String Specify the parameters to provide to the automake tool
Useful variables used to control the autogen.sh script :
To skip autoreconf and prepare manually: AUTORECONF=false ./autogen.sh
To verbosely try running with an older (unsupported) autoconf: AUTOCONF_VERSION=2.50 ./autogen.sh --verbose
AUTOMAKE_OPTIONS String Specify the parameters to provide to the automake tool
LIBTOOLIZE Boolean Enable/disable the libtoolize launch
LIBTOOL_VERSION String Specify a specific version for the autoconf package
LIBTOOLIZE_OPTIONS String Specify the parameters to provide to the libtoolize tool
ACLOCAL Boolean Enable/disable the aclocal launch
ACLOCAL_OPTIONS String Specify the parameters to provide to the aclocal tool
AUTOHEADER Boolean Enable/disable the autoheader launch
AUTOHEADER_OPTIONS String Specify the parameters to provide to the autoheader tool
CONFIG_GUESS_URL String URL where the latest config.guess file can be download

Impact on the autotools templates:
If we take the decision to use the autogen.sh script instead of the single autoreconf
command, this file is mandatorary to include in the tarball generated by the « make
dist » command.
EXTRA_DIST = $(top_builddir)/autogen.sh
The autogen.sh script should be within the files of the project.The autogen.sh script should be within the files of the project.
If this file is not added the tarball will miss this file and won’t be standalone!

The environment
PKGCONFIG LABPKGCONFIG LAB

Take an autotools project and check the differential before
and after the launch of the autogen.sh script.
Check with the autotools hierarchy poster provided.

Using libtool
The goal of this topic is to know how to uses libtool

Using libtool
GNU Libtool simplifies your job by encapsulating both the platform-specific dependencies, and the user interface, in
a single script. GNU Libtool is designed so that the complete functionality of each host type is available via a generic
interface, but nasty quirks are hidden from the programmer.
GNU Libtool's consistent interface is reassuring... users don't need to read obscure documentation in order to have
their favorite source package build shared libraries. They just run your package configure script (or equivalent), and
libtool does all the dirty work.
What libtool can do :

Using libtool
Libtool is a tool used:
The following issues need to be addressed in any reusable shared library system, specifically libtool:
The package installer should be able to control what sort of libraries are built.
It can be tricky to run dynamically linked programs whose libraries have not yet been installed. LD_LIBRARY_PATH must be set properly (if it is supported), or
programs fail to run.
The system must operate consistently even on hosts that don't support shared libraries.
The commands required to build shared libraries may differ wildly from host to host. These need to be determined at configure time in a consistent way. It is not
always obvious with what prefix or suffix a shared library should be installed. This makes it difficult for Makefile rules, since they generally assume that file names
are the same from host to host.
The system needs a simple library version number abstraction, so that shared libraries can be upgraded in place. The programmer should be informed how to design
the interfaces to the library to maximize binary compatibility. The install Makefile target should warn the package installer to set the proper environment variables
(LD_LIBRARY_PATH or equivalent), or run ldconfig.
Motivation for writing libtool :
(LD_LIBRARY_PATH or equivalent), or run ldconfig.
Since early 1995, several different GNU developers have recognized the importance of having shared library support for their packages. The primary motivation for
such a change is to encourage modularity and reuse of code (both conceptually and physically) in GNU programs.
Such a demand means that the way libraries are built in GNU packages needs to be general, to allow for any library type the package installer might want. The
problem is compounded by the absence of a standard procedure for creating shared libraries on different platforms.
The following sections outline the major issues facing shared library support in GNU, and how shared library support could be standardized with libtool.
The following specifications were used in developing and evaluating this system:
The system must be as elegant as possible.
The system must be fully integrated with the GNU Autoconf and Automake utilities, so that it will be easy for GNU maintainers to use. However, the system must not
require these tools, so that it can be used by non-GNU packages.
Portability to other (non-GNU) architectures and tools is desirable.

Using libtool
libtool libtool mode=link CC=sh4-linux-gcc .libs/foo.o –o foobin
libtool mode=compile CC=sh4-linux-gcc –c foo.c -o .libs/foo.o
$ libtool --mode=link gcc -g -O -o libhello.la foo.o hello.o
*** Warning: Linking the shared library libhello.la against the
*** non-libtool objects foo.o hello.o is not portable!
ar cru .libs/libhello.a
ranlib .libs/libhello.a
$ libtool --mode=compile gcc -g -O -c foo.c
mkdir .libs
gcc -g -O -c foo.c -fPIC -DPIC -o .libs/foo.o
gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1
libtool mode=install
Suffix used by libtool :
Extension’s name Library Binary
Objects .lo (library object) .o
Intermediate .la (library archive)
ranlib .libs/libhello.a
creating libhello.la
(cd .libs && rm -f libhello.la && ln -s ../libhello.la libhello.la)
$ libtool --mode=link gcc -g -O -o test test.o /usr/local/lib/libhello.la gcc -g -O -o
.libs/test test.o -Wl,--rpath -Wl,/usr/local/lib /usr/local/lib/libhello.a -lm creating test
$ libtool --mode=install cp libhello.la /usr/local/lib/libhello.la
cp libhello.la /usr/local/lib/libhello.la
cp .libs/libhello.a /usr/local/lib/libhello.a
ranlib /usr/local/lib/libhello.a

Using libtool
Libtool is a tool used: libtool [OPTION]... [MODE-ARG]...
Parameters Description
-n|--dry-run Don't create, modify, or delete any files, just show what commands would be executed by `libtool'
--mode=MODE Use MODE as the operation mode. By default, the operation mode is inferred from the MODE-ARGS
--features Display basic configuration options. This provides a way for packages to determine whether shared
or static libraries will be built
--finish Same as --mode=finish
--debug Dump a trace of shell script execution to standard output. This produces a lot of output, so you may
wish to pipe it to `less' (or `more') or redirect to a file
--config Display libtool configuration variables and exit
MODE Description
clean Remove files from the build directory
compile Compile a source file into a `libtool' object
execute Automatically set the library path, then run a program
finish Complete the installation of libtool libraries
install Install libraries or executables
link Create a library or an executable
uninstall Remove libraries from an installed directory
Listing of the several modes available:
--quiet
--silent
Don't print nformational messages.
--tag=TAG Use configuration variables from tag TAG

Using libtool
TAGs available :
Language name TAG name
C CC
C++ CXX
Java GCJ
Fortran 77 F77
Fortran FC
Windows resource RC
The same tags can be overwritten in the autotool context (this often do in aThe same tags can be overwritten in the autotool context (this often do in a
cross-compilation mode):
CC=sh4-linux-gcc CXX=sh4-linux-g++ ./configure --prefix=/usr …

Using libtool
$ libtool --mode=compile gcc -g -O -c foo.c
gcc -g -O -c foo.c -o foo.o
Compilation mode :
Compilation flag Description
-o Note that the -o option is now fully supported. It is emulated on the platforms that don't support it (by
locking and moving the objects), so it is really easy to use libtool, just with minor modifications to your
Makefiles.
Typing for example: libtool --mode=compile gcc -c foo/x.c -o foo/x.lo will do what you expect.
Note, however, that, if the compiler does not support -c and -o, it is impossible to compile foo/x.c without
overwriting an existing ./x.o.
Therefore, if you do have a source file ./x.c, make sure you introduce dependencies in your Makefile to
make sure ./x.o (or ./x.lo) is re-created after any sub-directory's x.lo: x.o x.lo: foo/x.lo bar/x.lomake sure ./x.o (or ./x.lo) is re-created after any sub-directory's x.lo: x.o x.lo: foo/x.lo bar/x.lo
This will also ensure that make won't try to use a temporarily corrupted x.o to create a program or library.
It may cause needless recompilation on platforms that support -c and -o together, but it's the only way to
make it safe for those that don't.
-no-suppress If both PIC and non-PIC objects are being built, libtool will normally suppress the compiler output for the
PIC object compilation to save showing very similar, if not identical duplicate output for each object. If
the -no-suppress option is given in compile mode, libtool will show the compiler output for both objects.
-prefer-pic Libtool will try to build only PIC objects.
-prefer-non-pic Libtool will try to build only non-PIC objects.
-shared Even if Libtool was configured with --enable-static, the object file Libtool builds will not be suitable for
static linking. Libtool will signal an error if it was configured with --disable-shared, or if the host does not
support shared libraries
-static Even if libtool was configured with --disable-static, the object file Libtool builds will be suitable for static
linking
-Wc,flag
-Xcompiler flag
Pass a flag directly to the compiler. With -Wc,, multiple flags may be separated by commas, whereas -
Xcompiler passes through commas unchanged

Using libtool
Link mode links together object files (including library objects) to form another library or to create an executable program.
mode-args consist of a command using the C compiler to create an output file (with the -o flag) from several object files. The following
components of mode-args are treated specially:
Link mode :
-all-static If output-file is a program, then do not link it against any shared libraries at all. If output-file is a library,
then only create a static library. In general, this flag cannot be used together with ‘disable-static’
-avoid-version Tries to avoid versioning for libraries and modules, i.e. no version information is stored and no symbolic links
are created. If the platform requires versioning, this option has no effect.
-bindir Pass the absolute name of the directory for installing executable programs. libtool may use this value to install
shared libraries there on systems that do not provide for any library hardcoding and use the directory of ashared libraries there on systems that do not provide for any library hardcoding and use the directory of a
program and the PATH variable as library search path. This is typically used for DLLs on Windows or other
systems using the PE (Portable Executable) format. On other systems, -bindir is ignored. The default value
used is libdir/../bin for libraries installed to libdir. You should not use -bindir for modules.
-dlopen file Same as -dlpreopen file, if native dlopening is not supported on the host platform or if the program is linked
with -static, -static-libtool-libs, or -all-static. Otherwise, no effect. If file is self Libtool will make sure that
the program can dlopen itself, either by enabling -export-dynamic or by falling back to -dlpreopen self.
-dlpreopen file Link file into the output program, and add its symbols to the list of preloaded symbols. If file is self, the
symbols of the program itself will be added to preloaded symbol lists. If fileis force Libtool will make sure that
a preloaded symbol list is always defined, regardless of whether it's empty or not.
-export-dynamic Allow symbols from output-file to be resolved with dlsym
-export-
symbols symfile
Tells the linker to export only the symbols listed in symfile. The symbol file should end in .sym and must
contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols
are exported.
-export-symbols-
regex regex
ame as -export-symbols, except that only symbols matching the regular expression regex are exported. By
default all symbols are exported.

Using libtool
-Llibdir Search libdir for required libraries that have already been installed
-lname output-file requires the installed library libname. This option is required even when output-file is not an
executable
-module reates a library that can be dlopened. This option doesn't work for programs. Module names don't need to be
prefixed with ‘lib’. In order to prevent name clashes, however, libname and name must not be used at the
same time in your package
-no-fast-install Disable fast-install mode for the executable output-file. Useful if the program won't be necessarily installed
-no-install Link an executable output-file that can't be installed and therefore doesn't need a wrapper script on systems
that allow hardcoding of library paths. Useful if the program is only used in the build tree, e.g., for testing or
Link mode (cont)
that allow hardcoding of library paths. Useful if the program is only used in the build tree, e.g., for testing or
generating other files.
-no-undefined Declare that output-file does not depend on any other libraries. Some platforms cannot create shared libraries
that depend on other libraries
-o output-file Create output-file from the specified objects and libraries.
-objectlist file Use a list of object files found in file to specify objects.
-precious-files-
regex regex
Prevents removal of files from the temporary output directory whose names match this regular expression.
You might specify ‘.bbg?$’ to keep those files created with gcc -ftest-coverage for example.
-release release Specify that the library was generated by release release of your package, so that users can easily tell which
versions are newer than others. Be warned that no two releases of your package will be binary compatible if
you use this flag. If you want binary compatibility, use the -version-info flag instead
-rpath libdir output-file is a library, it will eventually be installed in libdir. If output-file is a program, add libdir to the
run-time path of the program. On platforms that don't support hardcoding library paths into executables and
only search PATH for shared libraries, such as when output-file is a Windows (or other PE platform) DLL,
the .la control file will be installed in libdir, but see -bindir above for the eventual destination of the .dll or
other library file itself.

Using libtool
-R libdir If output-file is a program, add libdir to its run-time path. If output-file is a library, add -Rlibdir to
its dependency_libs, so that, whenever the library is linked into a program, libdir will be added to its run-time
path.
-shared If output-file is a program, then link it against any uninstalled shared libtool libraries (this is the default behavior).
If output-file is a library, then only create a shared library. In the later case, libtool will signal an error if it was
configured with --disable-shared, or if the host does not support shared libraries.
-shrext suffix If output-file is a libtool library, replace the system's standard file name extension for shared libraries
with suffix (most systems use .so here). This option is helpful in certain cases where an application requires that
shared libraries (typically modules) have an extension other than the default one. Please note you must supply the
full file name extension including any leading dot.
-static If output-file is a program, then do not link it against any uninstalled shared libtool libraries. If output-file is a
library, then only create a static library.
-static-libtool-libs If output-file is a program, then do not link it against any shared libtool libraries. If output-file is a library, then
only create a static library.
Link mode (cont)
only create a static library.
-version-
info current[:revision[:
age]]
If output-file is a libtool library, use interface version information current, revision, and age to build it. Do not use
this flag to specify package release information, rather see the -release flag.
-version-
number major[:minor[:
revision]]
If output-file is a libtool library, compute interface version information so that the resulting library uses the
specified major, minor and revision numbers. This is designed to permit libtool to be used with existing projects
where identical version numbers are already used across operating systems. New projects should use the -version-
info flag instead.
-weak libname if output-file is a libtool library, declare that it provides a weak libname interface. This is a hint to libtool that
there is no need to append libname to the list of dependency libraries of output-file, because linking
against output-file already supplies the same interface
-Wc,flag-
Xcompiler flag
Pass a linker-specific flag directly to the compiler. With -Wc,, multiple flags may be separated by commas,
whereas -Xcompiler passes through commas unchanged.
-Wl,flag-Xlinker flag Pass a linker-specific flag directly to the linker
-XCClinker flag Pass a link-specific flag to the compiler driver (CC) during linking.

If the output-file ends in .la, then a libtool library is created, which must be built only from library
objects (.lo files). The -rpath option is required. In the current implementation, libtool libraries may
not depend on other uninstalled libtool libraries.
If the output-file ends in .a, then a standard library is created using ar and possibly ranlib.
If output-file ends in .o or .lo, then a reloadable object file is created from the input files (generally
using ‘ld -r’). This method is often called partial linking.
Using libtool
Link mode (cont)
Otherwise, an executable program is created.

Using libtool
Execution mode :
For execute mode, the library path is automatically set, then a program is executed.
The first of the mode-args is treated as a program name, with the rest as arguments to that
program.
The following components of mode-args are treated specially:
-dlopen file Add the directory containing file to the library path
This mode sets the library path environment variable according to any -dlopen flags
If any of the args are libtool executable wrappers, then they are translated into the name of their
corresponding uninstalled binary, and any of their required library directories are added to the
library path.

Using libtool
Installation mode :
In install mode, libtool interprets most of the elements of mode-args as an installation command beginning with cp, or a BSD-compatible install
program.
The following components of mode-args are treated specially:
-inst-prefix-dir inst-prefix-dir
When installing into a temporary staging area, rather than the final prefix, this argument is used to reflect the temporary path, in much the
same way automake uses DESTDIR. For instance, if prefix is /usr/local, but inst-prefix-dir is /tmp, then the object will be installed under
/tmp/usr/local/. If the installed object is a libtool library, then the internal fields of that library will reflect only prefix, not inst-prefix-dir:
# Directory that this library needs to be installed in:
libdir='/usr/local/lib'
not
# Directory that this library needs to be installed in:
libdir='/tmp/usr/local/lib‘libdir='/tmp/usr/local/lib‘
inst-prefix is also used to insure that if the installed object must be relinked upon installation, that it is relinked against the libraries in inst-prefix-
dir/prefix, not prefix.
In truth, this option is not really intended for use when calling libtool directly; it is automatically used when libtool --mode=install calls libtool --
mode=relink. Libtool does this by analyzing the destination path given in the original libtool --mode=install command and comparing it to the
expected installation path established during libtool --mode=link.
Thus, end-users need change nothing, and automake-style make install DESTDIR=/tmp will Just Work(tm) most of the time. For systems where fast
installation can not be turned on, relinking may be needed. In this case, a ‘DESTDIR’ install will fail.
Currently it is not generally possible to install into a temporary staging area that contains needed third-party libraries which are not yet visible at their
final location.
The rest of the mode-args are interpreted as arguments to the cp or install command.
The command is run, and any necessary unprivileged post-installation commands are also completed.

Using libtool
Finish mode :
--dry-run Running this command may require superuser privileges, and the --dry-run option may be useful
Finish mode has two functions. One is to help system administrators install libtool libraries so that
they can be located and linked into user programs.
To invoke this functionality, pass the name of a library directory as mode-arg:
The second is to facilitate transferring libtool libraries to a native compilation environment afterThe second is to facilitate transferring libtool libraries to a native compilation environment after
they were built in a cross-compilation environment. Cross-compilation environments may rely on
recent libtool features, and running libtool in finish mode will make it easier to work with older
versions of libtool. This task is performed whenever the mode-arg is a .la file.

Using libtool
Uninstall mode :
Uninstall mode deletes installed libraries, executables and objects.
The first mode-arg is the name of the program to use to delete files (typically /bin/rm).
The remaining mode-args are either flags for the deletion program (beginning with a ‘-’), or the
names of files to delete.

Using libtool
Clean mode :
Clean mode deletes uninstalled libraries, executables, objects and libtool's temporary files associated
with them.
The first mode-arg is the name of the program to use to delete files (typically /bin/rm).
The remaining mode-args are either flags for the deletion program (beginning with a ‘-’), or the
names of files to delete.

Using libtool
LIBTOOL LABLIBTOOL LAB

Using libtool
The goal of this lab is to understand what libtool is really working.
Try to compile a helloworld.c source code by the two way:
gcc –c helloworld.c –o helloworld.o
Libtool --mode=compile gcc -c helloworld.c
Same for the link step (should create a helloworld binary):
gcc helloworld.o –o helloworld
libtool --mode=link gcc –o helloworld helloworld.o

The configure.{ac/in} template
The goal of this topic is to know how to write a configure.ac template.

The configure.{in/ac} template
A configure.ac is the template of the configure script that will be used by
the end user.
A configure.ac is written using M4 macros while a configure script is a
shell script.
The main goal of a configure script is to lead the configuration of a
component. The several flags provided to the configure script is like the ID
card of the build.card of the build.
The configure.ac teamplate is equal to the configure.in that is the old
notation.
Those script are executed like shell script at the runtime (no compiled).
Can build libraries, binaries, … in the same files, by managing
dependencies.

Check for programs
Check for (dynamic/static) libraries
Check for header files
Check for typedefs
Version management
Initialisation
Several usual steps
used by the configuration
script.
Check for structures
Check for compiler characteristics
Check for libraries functions
Check for system services
Generate output files
There is M4 macros for each step…
script.

Variable name Description
srcdir The name of the directory that contains the source code for that makefile.
top_srcdir The name of the top-level source code directory for the package. In the top-level directory, this is the same
as srcdir.
top_builddir The relative name of the top level of the current build tree. In the top-level directory, this is the same
as builddir.
abs_builddir Absolute name of builddir.
builddir Rigorously equal to ‘.’. Added for symmetry only.
top_build_prefix The relative name of the top level of the current build tree with final slash if nonemtpy. This is the same
Preset Output Variables :
Beware about all directories, because they can be override by configure options: ./configure –
prefix=/usr –srcdir=/tmp_srcdir …
If so, top_builddir can be different to top_srcdir and bring link problems, so be carefull !!
top_build_prefix The relative name of the top level of the current build tree with final slash if nonemtpy. This is the same
as top_builddir, except that it contains zero or more runs of ../, so it should not be appended with a slash for
concatenation. This helps for make implementations that otherwise do not treat ./file and file as equal in the
toplevel build directory.
abs_srcdir Absolute name of srcdir.
abs_top_srcdir Absolute name of top_srcdir.
abs_top_builddir Absolute name of top_builddir.

Variable name Description
LDFLAGS Options for the linker
LIBS -l options to pass to the linker. The default value is empty, but some Autoconf macros may prepend extra
libraries to this variable if those libraries are found and provide necessary functions. configure uses this
variable when linking programs to test for C, C++.
OBJCFLAGS Debugging and optimization options for the Objective C compiler. It acts like CFLAGS, but for Objective C
instead of C.
CXXFLAGS Debugging and optimization options for the C++ compiler. It acts like CFLAGS, but for C++ instead of C.
DEFS -D options to pass to the C compiler. If AC_CONFIG_HEADERS is called, configure replaces ‘@DEFS@’
Flags overriding :
http://www.gnu.org/software/hello/manual/autoconf/Preset-Output-Variables.html
DEFS -D options to pass to the C compiler. If AC_CONFIG_HEADERS is called, configure replaces ‘@DEFS@’
with -DHAVE_CONFIG_H instead. This variable is not defined while configure is performing its tests, only
when creating the output files.
CFLAGS Debugging and optimization options for the C compiler. If it is not set in the environment
when configure runs, the default value is set when you call AC_PROG_CC (or empty if you
don't).configure uses this variable when compiling or linking programs to test for C features.
CPPFLAGS Preprocessor options for the C, C++, Objective C, and Objective C++ preprocessors and compilers. If it is
not set in the environment when configure runs, the default value is empty.configure uses this variable
when preprocessing or compiling programs to test for C, C++, Objective C, and Objective C++ features.
configure_input A comment saying that the file was generated automatically by configure and giving the name of the
input file. AC_OUTPUT adds a comment line containing this variable to the top of every makefile it
creates. For other files, you should reference this variable in a comment at the top of each input file.
OBJCXXFLAGS Debugging and optimization options for the Objective C++ compiler. It acts like CXXFLAGS, but for
Objective C++ instead of C++.

Variable’s name Description Variable associated
CC C compiler CFLAGS
LD Linker LDFLAGS
CXX C++ compiler CXXFLAGS
TMPDIR Path used for compiling any source code
AR Tools used for creating static libraries
Tools overriding :
NM Tool used for extraing sysmbols
etc..
Examples:
./configure –prefix=/usrCC=gcc CFLAGS=-O3 LIBS=“-lposix” …
or
CC=sh4-linux-gcc AR=sha-linux-g++ ./configure –prefix=/usr …

Special Characters in Output Variables :
Many output variables are intended to be evaluated both by make and by the shell. Some
characters are expanded differently in these two contexts, so to avoid confusion these
variables' values should not contain any of the following characters: " # $ & ' ( ) * ; < > ? [
^ ` |
Also, these variables' values should neither contain newlines, nor start with ‘~’, nor contain
white space or ‘:’ immediately followed by ‘~’. The values can contain nonempty
sequences of white space characters like tabs and spaces, but each such sequence mightsequences of white space characters like tabs and spaces, but each such sequence might
arbitrarily be replaced by a single space during substitution.
These restrictions apply both to the values that configure computes, and to the values set
directly by the user. For example, the following invocations of configure are problematic,
since they attempt to use special characters within CPPFLAGS and white space
within $(srcdir):
CPPFLAGS='-DOUCH="&"#$*?"' '../My Source/ouch-1.0/configure'
'../My Source/ouch-1.0/configure' CPPFLAGS='-DOUCH="&"#$*?"'

Macros Definition
AC_INIT
Performs essential initialization for the generated configure script. It takes
as an argument a filename from the source directory, to ensure that the
source directory has been specified correctly.
AM_INIT_AUTOMAKE
Does all the standard initialization required by Automake and takes two
arguments, the package name and version number.
INTI_REQUIRED_VERSION Specifies the minimum required Inti version, in this case 1.0.7.
Some of the useful built-in M4 macros:
PKG_CHECK_MODULES
Checks for the specified version of the Inti library and if found places the
necessary include flags in $(INTI_CFLAGS) and the libraries to link with
$(INTI_LIBS). If the correct version is not found configure will report an error.
AC_PROG_CXX Checks for the C++ compiler and sets the variables CXX, GXX and CXXFLAGS.
AC_OUTPUT Must be called at the end of configure.in to create the Makefiles.
There are many others ; check the gnu/autoconf manual for more
Information (http://www.gnu.org/software/autoconf/manual/autoconf.pdf).

AC_PREREQ(2.59)
AC_INIT([pyPackage], [myPackageVersion], [thierry.gayet2@technicolor.com])
AC_ARG_ENABLE( debug,
AS_HELP_STRING([--enable-debug],
[enable debugging support]),
[enable_debug=$enableval],
[enable_debug=no] )
if test "$enable_debug" = "yes" ; then
CXXFLAGS="$CXXFLAGS -Wall -ggdb -O0"
Initialization
Check for the debug mode
Example of configure.{in/ac} template using some m4 macros :
CXXFLAGS="$CXXFLAGS -Wall -ggdb -O0"
AC_DEFINE(DEBUG, 1, [Define to enable debug build])
else
CXXFLAGS="$CXXFLAGS -Wall -O2"
fi
PKG_CHECK_MODULES([DIRECTFB],[directfb],[have_libdirectfb=yes],[have_libdirectfb=no])
if test "$have_libdirectfb" = no ; then
AC_MSG_ERROR([Missing directfb-1.4.1 library!!])
fi
AC_OUTPUT(Makefile) File to generate from the Makefile.am
template
Check for the libdirectfb library

dnl ---------------------------------------
dnl Load m4 macros
dnl ---------------------------------------
(…)
Adding comments or disabling lines into the configure.ac :
1. Official comments that are important and should stay in the configure.ac file using the dnl keyword :
2. Lines that are temporaly/definitively disabling in the configure file :
AC_CANONICAL_HOST
#AC_CANONICAL_TARGET
AC_SUBST(PACKAGE_VERSION)
Line disabled!!

Printing messages :
Configure scripts need to give users running them several kinds of information. The following macros print messages
in ways appropriate for each kind. The arguments to all of them get enclosed in shell double quotes, so the shell
performs variable and back-quote substitution on them. These macros are all wrappers around the echo shell command.
They direct output to the appropriate file descriptor:
Macro: AC_MSG_CHECKING (feature-description)
Notify the user that configure is checking for a particular feature. This macro prints a message that starts with
‘checking ’ and ends with ‘...’ and no newline. It must be followed by a call to AC_MSG_RESULT to print the result of
the check and the newline. The feature-descriptionshould be something like ‘whether the Fortran compiler accepts
C++ comments’ or ‘for c89’. This macro prints nothing if configure is run with the --quiet or --silent option. This is
quite similar to a echo -n.quite similar to a echo -n.
Macro: AC_MSG_RESULT (result-description)
Notify the user of the results of a check. result-description is almost always the value of the cache variable for the
check, typically ‘yes’, ‘no’, or a file name. This macro should follow a call to AC_MSG_CHECKING, and the result-
description should be the completion of the message printed by the call to AC_MSG_CHECKING. This macro prints
nothing if configure is run with the --quiet or --silent option. This is quite similar to an echo after an echo -n, so it will
be in the same line.
Example:
AC_MSG_CHECKING(“Checking something”)
(…)
Something tested here…The result is a boolean variable such as « bchkSomething »
(…)
AC_MSG_RESULT(bchkSomething)

Macros used for traces :
Macro: AC_MSG_NOTICE (message)
Deliver the message to the user. It is useful mainly to print a general description of the overall purpose of a group
of feature checks, e.g., AC_MSG_NOTICE([checking if stack overflow is detectable]). This macro prints nothing
if configure is run with the --quiet or --silent option.
Macro: AC_MSG_ERROR (error-description, [exit-status = ‘$?/1’])
Notify the user of an error that prevents configure from completing. This macro prints an error message to the
standard error output and exits configure with exit-status (‘$?’ by default, except that ‘0’ is converted to ‘1’). error-standard error output and exits configure with exit-status (‘$?’ by default, except that ‘0’ is converted to ‘1’). error-
description should be something like ‘invalid value $HOME for $HOME’. The error-description should start with
a lower-case letter, and “cannot” is preferred to “can't”.
Macro: AC_MSG_FAILURE (error-description, [exit-status])
This AC_MSG_ERROR wrapper notifies the user of an error that prevents configure from completing and that
additional details are provided in config.log. This is typically used when abnormal results are found during a
compilation.
Examples:
AC_MSG_NOTICE(“this is just a message”)

Initialisation of the configure script (including the requirements) :
The Autoconf language differs from many other computer languages because it treats actual code the same as plain text. Whereas in C,
for instance, data and instructions have different syntactic status, in Autoconf their status is rigorously the same. Therefore, we need a
means to distinguish literal strings from text to be expanded: quotation.
When calling macros that take arguments, there must not be any white space between the macro name and the open parenthesis.
AC_INIT([hello], [1.0]) # good
Arguments should be enclosed within the quote characters ‘[’ and ‘]’, and be separated by commas. Any leading blanks or newlines in
arguments are ignored, unless they are quoted. You should always quote an argument that might contain a macro name, comma,
parenthesis, or a leading blank or newline. This rule applies recursively for every macro call, including macros called from other
macros.
AC_COPYRIGHT (copyright-notice)
State that, in addition to the Free Software Foundation's copyright on the Autoconf macros, parts of your configure are covered by the
copyright-notice. The copyright-notice shows up in both the head of configure and in ‘configure --version’.
Some are mandatory :
o AC_INIT([pyPackage], [myPackageVersion], [thierry.gayet2@technicolor.com]) initializes autoconf with information
about your project, including the project name, version number, bug-reporting address, tarball name and the project
homepage.
o AC_PREREQ(2.59) specify the autoconf version
Others are not :
o AC_AUTOMAKE() adds several standard checks and initializes automake.
• AM_INIT_AUTOMAKE([1.10 no-define])
• AM_INIT_AUTOMAKE([1.10 no-define foreign]) specify that the component won’t use the GNU file (NEWS
README AUTHORS ChangeLog).

AC_CONFIG_SRCDIR(unique-file-in-source-dir)
unique-file-in-source-dir is some file that is in the package's source directory; configure checks for this file's existence to make sure that
the directory that it is told contains the source code in fact does. Occasionally people accidentally specify the wrong directory with --
srcdir; this is a safety check. Packages that do manual configuration or use the install program might need to tell configure where to find
some other shell scripts by calling AC_CONFIG_AUX_DIR, though the default places it looks are correct for most cases.
AC_CONFIG_AUX_DIR(dir)
Use the auxiliary build tools (e.g., install-sh, config.sub, config.guess, Cygnus configure, Automake and Libtool scripts, etc.) that are in
directory dir. These are auxiliary files used in configuration. dir can be either absolute or relative to srcdir. The default is srcdir or srcdir/..
or srcdir/../.., whichever is the first that contains install-sh. The other files are not checked for, so that using AC_PROG_INSTALL does
not automatically require distributing the other auxiliary files. It checks for install.sh also, but that name is obsolete because some make
have a rule that creates install from it if there is no makefile. The auxiliary directory is commonly named build-aux. If you need
PATH and source code definition :
have a rule that creates install from it if there is no makefile. The auxiliary directory is commonly named build-aux. If you need
portability to DOS variants, do not name the auxiliary directory aux.
AC_REQUIRE_AUX_FILE(file)
Declares that file is expected in the directory defined above. In Autoconf proper, this macro does nothing: its sole purpose is to be traced
by third-party tools to produce a list of expected auxiliary files. For instance it is called by macros like AC_PROG_INSTALL (see
Particular Programs) or AC_CANONICAL_BUILD (see Canonicalizing) to register the auxiliary files they need. Similarly, packages that
use aclocal should declare where local macros can be found using AC_CONFIG_MACRO_DIR.
AC_CONFIG_MACRO_DIR(dir)
Specify dir as the location of additional local Autoconf macros. This macro is intended for use by future versions of commands like
autoreconf that trace macro calls. It should be called directly from configure.ac so that tools that install macros for aclocal can find the
macros' declarations. Note that if you use aclocal from Automake to generate aclocal.m4, you must also set ACLOCAL_AMFLAGS = -I
dir in your top-level Makefile.am. Due to a limitation in the Autoconf implementation of autoreconf, these include directives currently
must be set on a single line in Makefile.am, without any backslash-newlines.

Checking for specific headers:
AC_CHECK_HEADERS([unistd.h])
Then you could have code like the following in conf.h.in. The conf.h created by configure defines ‘HAVE_UNISTD_H’ to 1, if and
only if the system has unistd.h.
/* Define as 1 if you have unistd.h. */ #undef HAVE_UNISTD_H
The format of the template file is stricter than what the C preprocessor is required to accept. A directive line should contain only
whitespace, ‘#undef’, and ‘HAVE_UNISTD_H’. The use of ‘#define’ instead of ‘#undef’, or of comments on the same line as
‘#undef’, is strongly discouraged. Each hook should only be listed once. Other preprocessor lines, such as ‘#ifdef’ or ‘#include’, are
copied verbatim from the template into the generated header.

Default prefix :
By default, configure sets the prefix for files it installs to /usr/local. The user of configure can select a different prefix using the --
prefix and --exec-prefix options. There are two ways to change the default: when creating configure, and when running it. Some software
packages might want to install in a directory other than /usr/local by default. To accomplish that, use the AC_PREFIX_DEFAULT macro.
AC_PREFIX_DEFAULT(prefix)
Set the default installation prefix to prefix instead of /usr/local.
It may be convenient for users to have configure guess the installation prefix from the location of a related program that they have
already installed. If you wish to do that, you can call AC_PREFIX_PROGRAM.
AC_PREFIX_PROGRAM(program)
If the user did not specify an installation prefix (using the --prefix option), guess a value for it by looking for program in PATH, the way
the shell does. If program is found, set the prefix to the parent of the directory containing program, else default the prefix as describedthe shell does. If program is found, set the prefix to the parent of the directory containing program, else default the prefix as described
above (/usr/local or AC_PREFIX_DEFAULT). For example, if program is gcc and the PATH contains /usr/local/gnu/bin/gcc, set the
prefix to /usr/local/gnu.
For example, if the AC_PREFIX_DEFAULT(/usr) is defined within a configure.ac, it won’t be mandatory to specify the prefix at the
configure launch.
If not we should mantadory specify the prefix: ./configure --prefix=/usr

In order to prevent autotools re-generating configure script automatically this is possible to
specify that we are in maintainer mode :
Sometimes due to the SCM not strictly remembering the timestamp of files the generated Makefile will think that it
needs to re-run "autoreconf -i" or equivalent to re-generate Makefile.in from Makefile.am, configure from
configure.ac, etc.
You need to look into maintainer mode - that should prevent the autoreconf step, which will fix the end-users'
problems.
In order to proceed, the following line should be add to the configure.ac:
AM_MAINTAINER_MODE
Or provide set the --enable-maintainer-mode parameter to the configure script :
./configure --prefix=/usr
--enable-maintainer-mode

Managing version numbers for dynamic libraries:
Your library can have two numbers - the 'release number' and the 'version number'.
The release number uses a scheme of your own devising. Generally it indicates how much functionality has been added since
the last version, and how many bugs were fixed.
The version number uses an established scheme to indicate what type of changes happened to your library's interface. The
following diagram can be found in many configure.ac files:
FOO_LIBRARY_RELEASE=2:1:3 FOO_LIBRARY_VERSION=3:0:0
current : revision : age
current : revision : age
Use this version number in your Makefile.am file:
lfoo_la_LDFLAGS= -version-info $(FOO_LIBRARY_VERSION) -release $(FOO_LIBRARY__RELEASE)
If the config.h header is used, the version will be pushed into this file. In the other case, it will be provided
into the compilation line. For a library, the delivery will generate a dynamic library using the version (eg:
libfake.so.1.0.2) using a symbolic link to the native dynamic library (eg: libfake.so). This is nice to also have a
buildin function (eg: get_API_version) that can provide the PACKAGE_VERSION metadata.
increment if interfaces have been added | | set to
zero if interfaces have been removed | | or changed
Increment if source code has changed | set to
zero if current is incremented
increment if interfaces have been added,
removed or changed

Numbers Definition
current The number of the current interface exported by the library. A current value of `0', means that you are
calling the interface exported by this library interface 0.
The version scheme used by Libtool tracks interfaces, where an interface is the set of exported entry
points into the library.
All Libtool libraries start with `-version-info' set to `0:0:0' -- this will be the default version number if
you don't explicitly set it on the Libtool link command line.
The meaning of these numbers (from left to right) is as follows:
calling the interface exported by this library interface 0.
revision The implementation number of the most recent interface exported by this library. In this case,
a revision value of `0' means that this is the first implementation of the interface.
If the next release of this library exports the same interface, but has a different implementation (perhaps
some bugs have been fixed), the revision number will be higher, but current number will be the same. In
that case, when given a choice, the library with the highest revision will always be used by the runtime
loader.
age The number of previous additional interfaces supported by this library. If age were `2', then this library can
be linked into executables which were built with a release of this library that exported the current
interface number, current, or any of the previous two interfaces. By definition age must be less than or
equal to current. At the outset, only the first ever interface is implemented, so age can only be `0'.
Beware, this can generate a warning if you want to generate a static library.

m4_define([gm_os_major_version], [1])
m4_define([gm_os_minor_version], [0])
m4_define([gm_os_micro_version], [0])
m4_define([gm_os_version],
[gm_os_major_version.gm_os_minor_version.gm_os_micro_version])
AC_INIT([gm_os_posix],[gm_os_version],[thierry.gayet2@technicolor.com])
LT_CURRENT=0
LT_REVISION=0
LT_AGE=0
AC_SUBST(LT_CURRENT)
In few steps, we can manage a package’s version:
 Configure.ac
AC_SUBST(LT_CURRENT)
AC_SUBST(LT_REVISION)
AC_SUBST(LT_AGE)
GM_OS_MAJOR_VERSION=gm_os_major_version
GM_OS_MINOR_VERSION=gm_os_minor_version
GM_OS_MICRO_VERSION=gm_os_micro_version
GM_OS_VERSION=gm_os_major_version.gm_os_minor_version.gm_os_micro_version
AC_SUBST(GM_OS_MAJOR_VERSION)
AC_SUBST(GM_OS_MINOR_VERSION)
AC_SUBST(GM_OS_MICRO_VERSION)
AC_SUBST(GM_OS_VERSION)
AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION)
 Configure.ac

 Makefile.am
lib_LTLIBRARIES = libtoe.la
libtoe_la_SOURCES = src/toe_assert.c
src/toe_memory.c
src/toe_thread.c
src/toe_messageQueue.c
inc/utlist.h
inc/internal_api.h
inc/internal_config.h
libtoe_la_CFLAGS = -I$(HEADER_DIR)
Example of Makefile.am template that use the version:
 Makefile.am
libtoe_la_CFLAGS = -I$(HEADER_DIR)
$(LIBCONFIG_CFLAGS)
$(LIBLOG_CFLAGS)
-DLOG_NAME=TOE
-DLOG_MASK_PRIO=LOG_PRIO_ALL
libtoe_la_LDFLAGS = -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
-lpthread
-lrt
libtoe_la_LIBADD = $(LIBCONFIG_LIBS)
$(LIBLOG_LIBS)
$(EFENCE_LIBS)

Then we can check if the tools needed for the compilation exist as well as their version:
Some are buildin m4 macro povided by the autoconf package :
AC_C_CONST
AC_ISC_POSIX
AC_HEADER_STDC
AC_PROG_CC
AC_PROG_CC_STDC
AC_PROG_CXX
Checking for the tools expected for the build:
AC_PROG_CXX
AC_PROG_CPP
AC_PROG_LN_S
AC_PROG_INSTALL
AC_PROG_LIBTOOL
AC_PROG_MAKE_SET
Others can be test manualy:
AC_PATH_PROG([PKG_CONFIG], [pkg-config])
if test -z "$PKG_CONFIG" ; then
AC_MSG_ERROR([pkg-config not found])
fi

Checking for the dependencies (static/dynamic libraries) :
For a complete automatic build process, it can be useful to get metadata from a library (version, name, cflags,
ldflags, …. ). This is what pkg-config brings to the OSS community:
Example: resolution of a dependancy:
# libglib2.0 dependency
PKG_CHECK_MODULES([GLIB2],[glib-2.0],[have_libglib=yes],[have_libglib=no])
if test "$have_libglib" = no ; then
AC_MSG_ERROR([Missing libglib-2.0 library])
else
AC_SUBST(GLIB2_CFLAGS)
AC_SUBST(GLIB2_CFLAGS)
AC_SUBST(GLIB2_LIBS)
fi
This will check the presence of the .pc file that contains the metdata (usually in /usr/local/lib/pkg-config):
$ pkg-config –-exist libname
The PKG_CONFIG_PATH should be set to the directory that contain the .pc files.
Then the M4 macro will export both the CFLAGS and the CFLAGS :
$ pkg-config –-cflags libname
$ pkg-config –-libs libname
This topic will be detail with the chapter related to pkg-config.

Managing subdirs using AC_CONFIG_SUBDIRS (dir ...)
Make AC_OUTPUT run configure in each subdirectory dir in the given blank-or-newline-separated list. Each dir should be a literal, i.e.,
please do not use:
if test "x$package_foo_enabled" = xyes; then
my_subdirs="$my_subdirs foo"
fi
AC_CONFIG_SUBDIRS([$my_subdirs])
because this prevents ‘./configure --help=recursive’ from displaying the options of the package foo. Instead, you should write:
if test "x$package_foo_enabled" = xyes; then
AC_CONFIG_SUBDIRS([foo])
fi
fi
If a given dir is not found at configure run time, a warning is reported; if the subdirectory is optional, write:
if test -d "$srcdir/foo"; then
AC_CONFIG_SUBDIRS([foo])
fi
If a given dir contains configure.gnu, it is run instead of configure. This is for packages that might use a non-Autoconf script
Configure, which can't be called through a configure wrapper since it would be the same file on case-insensitive file systems.
Likewise, if a dir contains configure.in but no configure, the Cygnus configure script found by AC_CONFIG_AUX_DIR is used.

Some operations are accomplished in several possible ways, depending on the OS variant. Checking for them essentially requires a
“case statement”. Autoconf does not directly provide one; however, it is easy to simulate by using a shell variable to keep track of
whether a way to perform the operation has been found yet.
Here is an example that uses the shell variable fstype to keep track of whether the remaining cases need to be checked. Note that
since the value of fstype is under our control, we don't have to use the longer ‘test "x$fstype" = xno’.
AC_MSG_CHECKING([how to get file system type])
fstype=no
# The order of these tests is important.
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/statvfs.h>
#include <sys/fstyp.h>]])],
[AC_DEFINE([FSTYPE_STATVFS], [1],
[Define if statvfs exists.])
fstype=SVR4])
fstype=SVR4])
if test $fstype = no; then
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/statfs.h>
#include <sys/fstyp.h>]])],
[AC_DEFINE([FSTYPE_USG_STATFS], [1],
[Define if USG statfs.])
fstype=SVR3])
fi
if test $fstype = no; then
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/statfs.h>
#include <sys/vmount.h>]])]),
[AC_DEFINE([FSTYPE_AIX_STATFS], [1],
[Define if AIX statfs.])
fstype=AIX])
fi
# (more cases omitted here)
AC_MSG_RESULT([$fstype])

Autotools

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Autotools

Similaire à Autotools (20)

Dernier

Dernier (20)

Autotools