Autotools pratical training


Published on

autotools practical training

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Autotools pratical training

  1. 1. Autotools introductionThe goal of this topic is to know how to well works with the autotools in a cross-compilation environement
  2. 2. The autotools process History : Historically, a shell configure script transformed a into a Makefile  Autoconf 1 (1992): autoconf transformed a into a configure file  Autoconf 2 (1994): added cross-compilation support, sub-directories, hidden results, more tests, …  Automake (1994): automake transformed a into a Makefile  Libtool (1996): changed the Automake behavior
  3. 3. Autotools introduction Here is the full power of the autotools in action that make build easier:
  4. 4. Autotools introductionAutotools is a collection of OSS tools : GNU Automake is a tool for automatically generating ` files compliant with the GNU Coding Standards. 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 orlater is recommended) before configuring Autoconf, so that Autoconfs 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). GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface.   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.    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, runningUNIX commands, doing integer arithmetic, manipulating text in various ways, recursion etc... m4 can be used either as a front-endto a compiler or as a macro processor in its own right.  (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).  A toolchain (GNU or other) that include binutils.
  5. 5. Autotools introduction Initial preparation :./ Configuration :./configure --prefix=/usr Compiling :make Installation :make DESTDIR=«stagingdir» install
  6. 6. Mastering the build processThe goal of this topic is to know how the build process works.
  7. 7. Mastering the build process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 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 thatyear. 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 anexample.
  8. 8. Mastering the build process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). 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 ofthe C standard library) that are platform dependent, and is required in order to compileusing 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 thedefault entry point (main). If there is no symbol named entry, the linker will try to parseentry as a number, and use that as the entry address (the number will be interpreted in base10; you may use a leading 0x for base 16, or a leading 0 for base 8).
  9. 9. Mastering the build process GNU tools from the toolchain are set for an embedded usage :--sysroot=staging directoryUse 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 toheader files.The GNU linker (beginning with version 2.16) has the necessary support for this option. If your linker does not support this option, theheader file aspect of --sysroot will still work, but the library aspect will not. 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"
  10. 10. Mastering the build process BUILD PORCESS LAB
  11. 11. Mastering the build processThe main goal of this lab is to know how is working theGNU/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 …
  12. 12. Quick GNU/make reminderThe goal of this topic is to know how works common GNU/make
  13. 13. Quick GNU/make reminder The final files generated are gnu/make based. Most can be extend with gnu/make features that‘s why this isimportant to know how makefiles are made. We will remain some basic makefile usage.
  14. 14. Quick GNU/make reminderWith GNU/Makefiles :  No target is buildin ; everything should be written from scratcheach 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 ;  Makefile are often more static than dynamic Everything done by gnu Makefile is automatically natively supported by the Autotools  !
  15. 15. Quick GNU/make reminder Other make engine exists: ocmake ( oqmake ( oand so on… For more information about the GNU/make:   NUMake-3.1.3.pdf      make_and_makefiles.pdf
  16. 16. Quick GNU/make reminder GNU/MAKE LAB
  17. 17. Quick GNU/make reminder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
  18. 18. Quick GNU/make reminder 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.
  19. 19. The autotools processThe goal of this topic is to know how works the templates are written.
  20. 20. The autotools process working with the autotools means for a developer to manage templates andpotfiles :  : used to define what should be build and how using generic templates.  : used to define an autotools project. It can include <component>.*.in : used to associate some metadata (this is used by * 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, … ).
  21. 21. The autotools processSTEP #1 : The 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: oa configure script from the oa form the oa if expected --- Roadmap : | | ------> autoconf* -----> configure [aclocal.m4] --+--- | | -----> autoheader* --> [] | [acsite.m4] ----- ------------------------------->
  22. 22. The autotools processSTEP #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: and so on…
  23. 23. The autotools process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, frequentdiversion 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 programsthat wrap autom4te, such as autoconf), in order to inspect when a macro is called and with which arguments. For example, when thisparagraph was written, the autoconf version could be found by: $ autoconf --trace=AC_INIT $ autoconf --trace=AC_INIT:version is $2‗ version is 2.63b.95-3963Another trick is to print out the expansion of various m4 expressions to standard error or to an independent file, with no further m4expansion, and without interfering with diversion changes or the post-processing done to standard output. m4_errprintn shows a givenexpression 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.acAC_INITm4_errprintn([The definition of AC_DEFINE_UNQUOTED:])m4_errprintn(m4_defn([AC_DEFINE_UNQUOTED]))AC_OUTPUTEOF$ autoconferror-->The definition of AC_DEFINE_UNQUOTED:error-->_AC_DEFINE_Q([], $@)
  24. 24. The autotools process• 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, 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, 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 projects headers and sources in the src subdirectory. There are three files:, helloworld.h and ;
  25. 25. The autotools process AUTOTOOLS LAB
  26. 26. The autotools processThe goal of this lab if to use an hello world autotools project.Experiment the several steps : Preparation: ./ See the files before and after. Configuration: ./configure –prefix=/usr Read the config.log that detail the configuration step ; this is a good way todebug a configure script. Compilation: make  Installation: make DESTDIR=pwd install  Delivery: make dist
  27. 27. Using the autoscan toolThe goal of this topic is to know how to use the autoscan tool
  28. 28. Using the autoscan toolSTEP #0 : autoscan The easiest way to create a (mostly) complete 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 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. 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  autoscan*  configure.scan 
  29. 29. Using the autoscan toolFirst exampleof the autoscan tool, two files should appear in the current directory: After the launch with an empty directory:  autoscan.log  configure.scan  should be renamed into a 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. 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
  30. 30. Using the autoscan tool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 3intmain(){ 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;}
  31. 31. Using the autoscan toolThat will automaticaly generate the following configure.scan script: # -*- 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 packages source directory. AC_CONFIG_HEADER([config.h])  containing C preprocessor #define statements. # Checks for programs. AC_PROG_CC  determine the C compiler to use. # Checks for libraries. # 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. To get a very basic, but working input file to autoconf, rename configure.scan to mv configure.scan Then update the AC_INIT macro, and add the AC_COPYRIGHT macro.
  32. 32. Using the autoscan tool AUTOSCAN LAB
  33. 33. Using the autoscan toolThe main goal for this lab is to go into a directory where isexisting source code ;Launch the autoscan command: ./autoscanView the configure.scan generated.
  34. 34. The scriptThe goal of this topic is to know how works the script
  35. 35. The script The script is used for converting all the templates (,, …) infinal files (Makefile, configure, …) needed for a common Autotools usage.Thus, The script (a.k.a. buildconf) provides automatic build system preparation and isgenerally 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 forcompilation, verifying versions, ensuring necessary functionality, and overcoming many commonbuild preparation issues.Official web site : : BSDLatest stable release : 23.12.2009This script is standalone, its usage is mainly limited to a call in the autotools directory : $ ./Another way is to use the following command: autoreconf -i –force (This is what the script do in background)
  36. 36. The script  Before the autoconf script some bootstrap command was used: first, we need to generate the required output files from the two input files and First we need tocollect all the macro invocations in that Autoconf will need to build the configure script. This is done with thefollowing command:$ aclocalThis 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. Its important to run aclocal first becauseautomake relies on the contents on 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 willreport an error. Enter the following command to create these files:$ touch AUTHORS NEWS README ChangeLog Now we can run automake to create The –add-missing argument copies some boilerplate files from yourAutomake installation into the current directory.$ automake --add-missingBy now, the contents of the directory should be looking a lot like the top-level directory of a GNU package you may haveinstalled before:
  37. 37. The scriptWhat the really do : It tranforms the template into intermediate files:Those files will complete the other files (, in order to beready for the configure script.Note : is by far the preferred naming for autoconf >= 2.50 is what was used by autoconf ⇐ 2.13 and was kept for *cough*backward compatibility *cough*…
  38. 38. The script  Parameters used to control the script :  There is two controversal parameters with the --quiet and --verbose that can be set in the same time!! Indeed, the script will follow the last one provided at the launch.  Check of the autotools components version:$ ./ –version Identical as :Preparing the toe build system...please wait ./autoconf --versionFound GNU Autoconf version 2.67Found GNU Automake version 1.11.1 ./automake –versionFound GNU Libtool version 2.2.6b ./libtool 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-2009script version 20090301, ISO/IEC 9945 POSIX shell script---Version requested. No preparation or configuration will be performed.
  39. 39. The script  usage can be obtain with the command line:$ ./ –helpUsage: ./ [-h|--help] [-v|--verbose] [-q|--quiet] [-d|--download] [--version] --help Help on 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 checksDescription: This script will validate that minimum versions of theGNU Build System tools are installed and then run autoreconf for you.Should autoreconf fail, manual preparation steps will be runpotentially accounting for several common preparation issues. TheAUTORECONF, AUTOCONF, AUTOMAKE, LIBTOOLIZE, ACLOCAL, AUTOHEADER,PROJECT, & CONFIGURE environment variables and corresponding _OPTIONSvariables (e.g. AUTORECONF_OPTIONS) may be used to override thedefault automatic detection 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-2009script version 20090301, ISO/IEC 9945 POSIX shell script---Help was requested. No preparation or configuration will be performed.
  40. 40. The script $ ./ –verbose Silent launch (default): Verbose output enabled Found a configure template: ./ Preparing the toe build system...please wait Checking autoreconf version: autoreconf --version$ ./ Checking autoconf version: autoconf --versionPreparing the toe build system...please wait Found GNU Autoconf version 2.67 Checking if 2.67.0 is greater than 2.52.0 Checking automake version: automake --version  Verbose launch Found GNU Automake version 1.11.1 Checking if 1.11.1 is greater than 1.6.0Found GNU Autoconf version 2.67 Checking libtoolize version: libtoolize --version Found GNU Libtool version 2.2.6bFound GNU Automake version 1.11.1 Checking if 2.2.6 is greater than 1.4.2Found GNU Libtool version 2.2.6b Checking aclocal version: aclocal --version Checking autoheader version: autoheader --version Checking whether to only output version informationAutomatically preparing build ... done 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.backupThe toe build system is now prepared. To build here, run: Found an autom4te.cache directory, deleting it ./configure rm -rf autom4te.cache make mv -f "./config.guess" "./config.guess.backup" mv -f "./config.sub" "./config.sub.backup" mv -f "./" "./" 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 `./ libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4]) to and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4 to ACLOCAL_AMFLAGS in 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 "./" 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 "./"
  41. 41. The script Useful variables used to control the script :To skip autoreconf and prepare manually: AUTORECONF=false./To verbosely try running with an older (unsupported) autoconf: AUTOCONF_VERSION=2.50 ./
  42. 42. The scriptImpact on the autotools templates:If we take the decision to use the script instead of the single autoreconfcommand, this file is mandatorary to include in the tarball generated by the « makedist » command. EXTRA_DIST = $(top_builddir)/autogen.shThe 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!
  43. 43. The environment AUTOGEN.SH LAB
  44. 44. The scriptTake an autotools project and check the differential beforeand after the launch of the script. Check with: autoreconf –i –force Check with the autotools hierarchy poster provided.
  45. 45. Using libtoolThe goal of this topic is to know how to uses libtool
  46. 46. Using libtool  What libtool can do :GNU Libtool simplifies your job by encapsulating both the platform-specific dependencies, and the user interface, ina single script. GNU Libtool is designed so that the complete functionality of each host type is available via a genericinterface, but nasty quirks are hidden from the programmer.GNU Libtools consistent interface is reassuring... users dont need to read obscure documentation in order to havetheir favorite source package build shared libraries. They just run your package configure script (or equivalent), andlibtool does all the dirty work.
  47. 47. 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), orprograms fail to run.The system must operate consistently even on hosts that dont 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 notalways 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 namesare the same from host to host. Motivation for writing libtool :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 designthe 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.Since early 1995, several different GNU developers have recognized the importance of having shared library support for their packages. The primary motivation forsuch 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. Theproblem 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 notrequire these tools, so that it can be used by non-GNU packages.
  48. 48. Using libtool Libtool is a tool used: libtool [OPTION]... [MODE-ARG]... Listing of the several modes available:
  49. 49. Using libtool TAGs available :The same tags can be overwritten in the autotool context (this often do in across-compilation mode): CC=sh4-linux-gcc CXX=sh4-linux-g++ ./configure --prefix=/usr …
  50. 50. Using libtool Compilation mode : $ libtool --mode=compile gcc -g -O -c foo.c gcc -g -O -c foo.c -o foo.o
  51. 51. Using libtool Link mode :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 followingcomponents of mode-args are treated specially:
  52. 52. Using libtool Link mode (cont)
  53. 53. Using libtool Link mode (cont)
  54. 54. Using libtool Link mode (cont)If the output-file ends in .la, then a libtool library is created, which must be built only from libraryobjects (.lo files). The -rpath option is required. In the current implementation, libtool libraries maynot 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 (generallyusing ‗ld -r‘). This method is often called partial linking.Otherwise, an executable program is created.
  55. 55. 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 thatprogram.The following components of mode-args are treated specially:If any of the args are libtool executable wrappers, then they are translated into the name of theircorresponding uninstalled binary, and any of their required library directories are added to thelibrary path.
  56. 56. 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 installprogram.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 willreflect 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‗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 theexpected 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 fastinstallation 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 theirfinal location.The rest of the mode-args are interpreted as arguments to the cp or install command.
  57. 57. Using libtool Finish mode :Finish mode has two functions. One is to help system administrators install libtool libraries so thatthey 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 afterthey were built in a cross-compilation environment. Cross-compilation environments may rely onrecent libtool features, and running libtool in finish mode will make it easier to work with olderversions of libtool. This task is performed whenever the mode-arg is a .la file.
  58. 58. 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 thenames of files to delete.
  59. 59. Using libtool Clean mode :Clean mode deletes uninstalled libraries, executables, objects and libtools temporary files associatedwith 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 thenames of files to delete.
  60. 60. Using libtool LIBTOOL LAB
  61. 61. 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
  62. 62. The configure.{ac/in} templateThe goal of this topic is to know how to write a template.
  63. 63. The configure.{in/ac} template A is the template of the configure script that will be used bythe end user. A is written using M4 macros while a configure script is ashell script. The main goal of a configure script is to lead the configuration of acomponent. The several flags provided to the configure script is like the IDcard of the build.The teamplate is equal to the that is the oldnotation.Those script are executed like shell script at the runtime (no compiled).Can build libraries, binaries, … in the same files, by managingdependencies.
  64. 64. The configure.{in/ac} template 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 !!
  65. 65. The configure.{in/ac} template  Flags overriding :
  66. 66. The configure.{in/ac} template  Tools overriding :Examples: ./configure –prefix=/usrCC=gcc CFLAGS=-O3 LIBS=―-lposix‖ … or CC=sh4-linux-gcc AR=sha-linux-g++ ./configure –prefix=/usr …
  67. 67. The configure.{in/ac} template Special Characters in Output Variables :Many output variables are intended to be evaluated both by make and by the shell. Somecharacters are expanded differently in these two contexts, so to avoid confusion thesevariables values should not contain any of the following characters: " # $ & ( ) * ; < > ? [^`|Also, these variables values should neither contain newlines, nor start with ‗~‘, nor containwhite space or ‗:‘ immediately followed by ‗~‘. The values can contain nonemptysequences of white space characters like tabs and spaces, but each such sequence mightarbitrarily be replaced by a single space during substitution.These restrictions apply both to the values that configure computes, and to the values setdirectly by the user. For example, the following invocations of configure are problematic,since they attempt to use special characters within CPPFLAGS and white spacewithin $(srcdir): CPPFLAGS=-DOUCH="&"#$*?" ../My Source/ouch-1.0/configure ../My Source/ouch-1.0/configure CPPFLAGS=-DOUCH="&"#$*?"
  68. 68. The configure.{in/ac} template Some of the useful built-in M4 macros: There are many others ; check the gnu/autoconf manual for more Information (
  69. 69. The configure.{in/ac} template Printing messages :Configure scripts need to give users running them several kinds of information. The following macros print messagesin ways appropriate for each kind. The arguments to all of them get enclosed in shell double quotes, so the shellperforms 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 ofthe check and the newline. The feature-descriptionshould be something like „whether the Fortran compiler acceptsC++ comments‟ or „for c89‟. This macro prints nothing if configure is run with the --quiet or --silent option. This isquite 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 thecheck, 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 printsnothing if configure is run with the --quiet or --silent option. This is quite similar to an echo after an echo -n, so it willbe 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)
  70. 70. The configure.{in/ac} template 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 groupof feature checks, e.g., AC_MSG_NOTICE([checking if stack overflow is detectable]). This macro prints nothingif 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 thestandard 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 witha lower-case letter, and “cannot” is preferred to “cant”. 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 thatadditional details are provided in config.log. This is typically used when abnormal results are found during acompilation.Examples: AC_MSG_NOTICE(“this is just a message”)
  71. 71. The configure.{in/ac} template 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 ameans 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]) # goodArguments should be enclosed within the quote characters ‗[‘ and ‗]‘, and be separated by commas. Any leading blanks or newlines inarguments 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 othermacros. AC_COPYRIGHT (copyright-notice)State that, in addition to the Free Software Foundations copyright on the Autoconf macros, parts of your configure are covered by thecopyright-notice. The copyright-notice shows up in both the head of configure and in ‗configure --version‘. Some are mandatory : o AC_INIT([pyPackage], [myPackageVersion], [])  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
  72. 72. The configure.{in/ac} template  PATH and source code definition :AC_CONFIG_SRCDIR(unique-file-in-source-dir)unique-file-in-source-dir is some file that is in the packages source directory; configure checks for this files existence to make sure thatthe 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 findsome 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 indirectory 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 doesnot automatically require distributing the other auxiliary files. It checks for also, but that name is obsolete because some makehave a rule that creates install from it if there is no makefile. The auxiliary directory is commonly named build-aux. If you needportability 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 tracedby third-party tools to produce a list of expected auxiliary files. For instance it is called by macros like AC_PROG_INSTALL (seeParticular Programs) or AC_CANONICAL_BUILD (see Canonicalizing) to register the auxiliary files they need. Similarly, packages thatuse 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 likeautoreconf that trace macro calls. It should be called directly from so that tools that install macros for aclocal can find themacros declarations. Note that if you use aclocal from Automake to generate aclocal.m4, you must also set ACLOCAL_AMFLAGS = -Idir in your top-level Due to a limitation in the Autoconf implementation of autoreconf, these include directives currentlymust be set on a single line in, without any backslash-newlines.
  73. 73. The configure.{in/ac} template Checking for specific headers: AC_CHECK_HEADERS([unistd.h])Then you could have code like the following in The conf.h created by configure defines ‗HAVE_UNISTD_H‘ to 1, if andonly if the system has unistd.h. /* Define as 1 if you have unistd.h. */ #undef HAVE_UNISTD_HThe format of the template file is stricter than what the C preprocessor is required to accept. A directive line should contain onlywhitespace, ‗#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‘, arecopied verbatim from the template into the generated header.
  74. 74. The configure.{in/ac} template  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 softwarepackages 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 havealready 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 waythe shell does. If program is found, set the prefix to the parent of the directory containing program, else default the prefix as describedabove (/usr/local or AC_PREFIX_DEFAULT). For example, if program is gcc and the PATH contains /usr/local/gnu/bin/gcc, set theprefix to /usr/local/gnu.For example, if the AC_PREFIX_DEFAULT(/usr) is defined within a, it won‘t be mandatory to specify the prefix at theconfigure launch.If not we should mantadory specify the prefix: ./configure --prefix=/usr
  75. 75. The configure.{in/ac} template In order to prevent autotools re-generating configure script automatically this is possible tospecify that we are in maintainer mode :Sometimes due to the SCM not strictly remembering the timestamp of files the generated Makefile will think that itneeds to re-run "autoreconf -i" or equivalent to re-generate from, configure, etc.You need to look into maintainer mode - that should prevent the autoreconf step, which will fix the end-usersproblems.In order to proceed, the following line should be add to the AM_MAINTAINER_MODEOr provide set the --enable-maintainer-mode parameter to the configure script : ./configure --prefix=/usr --enable-maintainer-mode
  76. 76. The configure.{in/ac} templateThe version scheme used by Libtool tracks interfaces, where an interface is the set of exported entrypoints into the library.All Libtool libraries start with `-version-info set to `0:0:0 -- this will be the default version number ifyou dont explicitly set it on the Libtool link command line.The meaning of these numbers (from left to right) is as follows: Beware, this can generate a warning if you want to generate a static library.
  77. 77. The configure.{in/ac} template  Example of template that use the version:lib_LTLIBRARIES = libtoe.lalibtoe_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.hlibtoe_la_CFLAGS = -I$(HEADER_DIR)  $(LIBCONFIG_CFLAGS) $(LIBLOG_CFLAGS) -DLOG_NAME=TOE -DLOG_MASK_PRIO=LOG_PRIO_ALLlibtoe_la_LDFLAGS = -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) -lpthread -lrt
  78. 78. The configure.{in/ac} template 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]) fiIf 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 scriptConfigure, which cant be called through a configure wrapper since it would be the same file on case-insensitive file systems. Likewise, if a dir contains but no configure, the Cygnus configure script found by AC_CONFIG_AUX_DIR is used.
  79. 79. The configure.{in/ac} template 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 ofwhether 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 thatsince the value of fstype is under our control, we dont 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]) 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])
  80. 80. The configure.{in/ac} template  Creating variables exported to the Makefiles :AC_DEFINE (variable, value, [description])AC_DEFINE (variable)Define variable to value (verbatim), by defining a C preprocessor macro for variable. variable should be a C identifier, optionally suffixedby a parenthesized argument list to define a C preprocessor macro with arguments. The macro argument list, if present, should be acomma-separated list of C identifiers, possibly terminated by an ellipsis ‗...‘ if C99 syntax is employed. variable should not containcomments, white space, trigraphs, backslash-newlines, universal character names, or non-ASCII characters.value may contain backslash-escaped newlines, which will be preserved if you use AC_CONFIG_HEADERS but flattened if passed via@DEFS@ (with no effect on the compilation, since the preprocessor sees only one line in the first place). value should not contain rawnewlines. If you are not using AC_CONFIG_HEADERS, value should not contain any ‗#‘ characters, as make tends to eat them. To use ashell variable, use AC_DEFINE_UNQUOTED instead.description is only useful if you are using AC_CONFIG_HEADERS. In this case, description is put into the generated as thecomment before the macro define. The following example defines the C preprocessor variable EQUATION to be the string constant ‗"$a> $b"‘: AC_DEFINE([EQUATION], ["$a > $b"], [Equation string.])If neither value nor description are given, then value defaults to 1 instead of to the empty string. This is for backwards compatibility witholder versions of Autoconf, but this usage is obsolescent and may be withdrawn in future versions of Autoconf.If the variable is a literal string, it is passed to m4_pattern_allow.If multiple AC_DEFINE statements are executed for the same variable name (not counting any parenthesized argument list), the last onewins.
  81. 81. The configure.{in/ac} templateAC_DEFINE_UNQUOTED (variable, value, [description])AC_DEFINE_UNQUOTED (variable)Like AC_DEFINE, but three shell expansions are performed—once—on variable and value: variable expansion (‗$‘), commandsubstitution (‗`‘), and backslash escaping (‗‘), as if in an unquoted here-document. Single and double quote characters in the value haveno special meaning. Use this macro instead of AC_DEFINE when variable or value is a shell variable. Examples: AC_DEFINE_UNQUOTED([config_machfile], ["$machfile"], [Configuration machine file.]) AC_DEFINE_UNQUOTED([GETGROUPS_T], [$ac_cv_type_getgroups], [getgroups return type.]) AC_DEFINE_UNQUOTED([$ac_tr_hdr], [1], [Translated header name.])Due to a syntactical bizarreness of the Bourne shell, do not use semicolons to separate AC_DEFINE or AC_DEFINE_UNQUOTEDcalls from other macro calls or shell code; that can cause syntax errors in the resulting configure script. Use either blanks or newlines.That is, do this: AC_CHECK_HEADER([elf.h], [AC_DEFINE([SVR4], [1], [System V Release 4]) LIBS="-lelf $LIBS"])or this: AC_CHECK_HEADER([elf.h], [AC_DEFINE([SVR4], [1], [System V Release 4]) LIBS="-lelf $LIBS"])instead of this:
  82. 82. The configure.{in/ac} templateAC_SUBST (variable, [value])Create an output variable from a shell variable. Make AC_OUTPUT substitute the variable variable into output files (typically one ormore makefiles). This means that AC_OUTPUT replaces instances of ‗@variable@‘ in input files with the value that the shell variablehas when AC_OUTPUT is called.The value can contain any non-NUL character, including newline. If you are using automake 1.11 or newer, for newlines in values youmight want to consider using AM_SUBST_NOTMAKE to prevent automake from adding a line variable = @variable@ to files (see automake).Variable occurrences should not overlap: e.g., an input file should not contain ‗@var1@var2@‘ if var1 and var2 are variable names.The substituted value is not rescanned for more output variables; occurrences of ‗@variable@‘ in the value are inserted literally into theoutput file. (The algorithm uses the special marker |#_!!_#| internally, so neither the substituted value nor the output file may contain|#_!!_#|.)If value is given, in addition assign it to variable. All the variables defined by : •AC_SUBST() •AC_DEFINED_*() •AM_CONDITIONAL() •… can be used in the
  83. 83. The configure.{in/ac} templateAM_CONDITIONAL (conditional, condition):The conditional name, conditional, should be a simple string starting with a letter and containing only letters, digits, and underscores. Itmust be different from ‗TRUE‘ and ‗FALSE‘ that are reserved by automake.The shell condition (suitable for use in a shell if statement) is evaluated when configure is run. Note that you must arrange for everyAM_CONDITIONAL to be invoked every time configure is run. If AM_CONDITIONAL is run conditionally (e.g., in a shell ifstatement), then the result will confuse automake.Conditionals typically depend upon options that the user provides to the configure script. Here is an example of how to write aconditional that is true if the user uses the --enable-debug option. AC_ARG_ENABLE([debug], [ --enable-debug Turn on debugging], [case "${enableval}" in yes) debug=true ;; no) debug=false ;; *) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;; esac],[debug=false]) AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])Here is an example of how to use that conditional in if DEBUG DBG = debug_program else DBG = endif noinst_PROGRAMS = $(DBG)
  84. 84. The configure.{in/ac} templateAM_COND_IF (conditional, [if-true], [if-false])If conditional is fulfilled, execute if-true, otherwise execute if-false. If either branch contains AC_CONFIG_FILES, it will causeautomake to output the rules for the respective files only for the given condition.AM_COND_IF macros may be nested when m4 quotation is used properly (see M4 Quotation).Here is an example of how to define a conditional config file: AM_CONDITIONAL([SHELL_WRAPPER], [test "x$with_wrapper" = xtrue]) AM_COND_IF([SHELL_WRAPPER], [AC_CONFIG_FILES([])])
  85. 85. The configure.{in/ac} templateAC_ARG_WITH (package, help-string, [action-if-given], [action-if-not-given])If the user gave configure the option --with-package or --without-package, run shell commands action-if-given. If neither option wasgiven, run shell commands action-if-not-given. The name package indicates another software package that this program should workwith. It should consist only of alphanumeric characters, dashes, plus signs, and dots.The options argument is available to the shell commands action-if-given in the shell variable with val, which is actually just the valueof the shell variable named with_package, with any non-alphanumeric characters in package changed into ‗_‘. You may use thatvariable instead, if you wish.The argument help-string is a description of the option that looks like this: --with-readline support fancy command line editing AC_ARG_WITH([readline],help-string may be more than one line long, if more detail is needed. Just make sure the columns line up in ‗configure --help‘. Avoid [AS_HELP_STRING([--without-readline],tabs in the help string [disable support for readline])], [], [with_readline=yes]) LIBREADLINE= AS_IF([test "x$with_readline" != xno], [AC_CHECK_LIB([readline], [main], [AC_SUBST([LIBREADLINE], ["-lreadline -lncurses"]) AC_DEFINE([HAVE_LIBREADLINE], [1], [Define if you have libreadline]) ], [AC_MSG_FAILURE( [readline test failed (--without-readline to disable)])], [-lncurses])])
  86. 86. The configure.{in/ac} templateConfiguring Other Packages in SubdirectoriesIn most situations, calling AC_OUTPUT is sufficient to produce makefiles in subdirectories. However, configure scripts that control more than oneindependent package can use AC_CONFIG_SUBDIRS to run configure scripts for other packages in subdirectories. 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 notuse: 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]) fiIf 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]) fiIf 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 cant becalled through a wrapper configure since it would be the same file on case-insensitive file systems. Likewise, if a dir butno configure, the Cygnus configure script found by AC_CONFIG_AUX_DIR is used.The subdirectory configure scripts are given the same command lineoptions that were given to this configure script, with minor changes if needed, which include:· adjusting a relative name for the cache file;· adjusting a relative name for the source directory;· propagating the current value of $prefix, including if it was defaulted, and if the default values of the top level and of thesubdirectory configure differ.This macro also sets the output variable subdirs to the list of directories ‗dir ...‟. Make rules can use this variable todetermine which subdirectories to recurse into.This macro may be called multiple times.
  87. 87. The configure.{in/ac} templateGenerating final files :It can be Makefiles, .pc files, config.h headers and so on : AC_CONFIG_FILES([ Makefile src/Makefile  New format foo.pc ]) AC_OUTPUT It can be Makefiles, .pc files, config.h headers and so on : AC_OUTPUT([ Makefile src/Makefile  Old deprecated format foo.pc ])  Both format are functional. The first one is the best format. It is the new one with new being relative because it has been that way for a while. The last one is the old format from way long ago.
  88. 88. The configure.{in/ac} template CONFIGURE LAB
  89. 89. The configure.{in/ac} templateThe main goal for this lab is to write a basic configure that : Check the C compiler Check Some standard headers Generate a Makefile in outputIn case of problems with configure, you can consult the―config.log‖ file that may provide more information about anAutotools problem.Read the ./configure --help to know all the parameters thatcan be used by this script.
  90. 90. The templateThe goal of this topic is to know how to write a template.
  91. 91. The templatesA template will use a context prepared by the configure script. This is the second most important template after theA GNU/Makefile can support more than one target. According to the final binary to build (binary, library, … ), the Makefile will runthem one by one in the same order than written in the template.As seen before, are generic template ready for a conversion into The, contains variables between arobases in order to make the update bythe configure script easy to do.
  92. 92. The templates Template definition for binaries and libraries :
  93. 93. The templates
  94. 94. The templates
  95. 95. The templates Variables used when building a program :Occasionally it is useful to know which `Makefile variables Automake uses for compilations; for instance youmight need to do your own compilation in some special cases. Some variables are inherited from Autoconf; theseare CC, CFLAGS, CPPFLAGS, DEFS, LDFLAGS, and LIBS. There are some global additional variables which Automake itself defines:  This impact all components from the (binary, libarry, … )
  96. 96. The templates MAKEFILE.AM LAB
  97. 97. The templatesThe main goal for this lab is to :1.Write a that will call another Makefile locatedinto a src directory1.In this second, just generate a binary froma helloworld.c.1.Managed them using a single
  98. 98. Using the library templateThe goal of this topic is to know how to generate static/dynamic libraries.
  99. 99. Using the library template Autotools template make the makefile standard and portable.Writting a library is quite identical as a binary.A library either static or dynamic should also export its public api: <STAGINGDIR>/<PREFIX>/include/  public headers <STAGINGDIR>/<PREFIX>/include/prefix/  metadata (.pc files) <STAGINGDIR>/<PREFIX>/lib/  static and/oBy default, the configure script generate both a static and dynamic library:This is possible so specify just one type:./configure --disable-static : generate only a dynamic one./configure –disable-dynamic : force to generate only a static one
  100. 100. Using the library template  Linking with a mix of shared and static librariesBy default, the linker will link against the shared libraries if they are available. If the -static flag isgiven, the linker will try to use static libraries instead of dynamic one. But -Bdynamic and -Bstaticprovides finer control of which library, shared or static should searched for each library specified forthe linker. The library search option is toggled by each -Bdynamic or -Bstatic: ld ... -Bstatic -lfoo -Bdynamic -lbar ....This command tells the linker to search the static library for libfoo, and search the shared version forlibbar and any libraries after it until a -Bstatic is seen.To pass the -Bdynamic and -Bstatic options to the linker, one needs to do gcc -o main main.o -Wl,-Bstatic -lfoo -Wl,-Bdynamic –lbarSince the gcc driver calls the linker with some default libraries, gcc -o main main.o -Wl,-Bstatic tells the linker to use the static versions for all default libraries like libc and etc.
  101. 101. Using the library template  Memory slicing with dynamic libraries :Dynamic libraries are mapped by the dynamic linker in the process addressspace, CODE BSS All processes share the same dynamic library code segment, HEAP CODE LIB 1Each dynamic library data segment is of course per process, DATA CODE  Each dynamic library data size must be counted in the process memory LIB 2 consumption. DATA Stack
  102. 102. Using the library template Now withthe autotools 
  103. 103. Using the library templateThis is possible to force the generation of a static library in case of a Makefile that generatea static one before to link with :noinst_lib_LTLIBRARIES = libfoo.laThe binary will be link using the internal LDFALGS.Nb : the noinst prefix say that the library won‘t be install by the make install command.The following prefix are accepted : check_LTLIBRARIES : generate a library for unitary tests noinst_LTLIBRARIES : generate a library for local usage (won‘t be installed)
  104. 104. Using the library template LIBRARY LAB
  105. 105. Using the library template The main goal of this lab is to generate a library.The library have two source code lib01.c and lib02.c located intoa src directory. The configure script should managed the version.A single Makefile should be able to compile either a static or adynamic one.
  106. 106. Using the application templateThe goal of this topic is to know how to generate binaries.
  107. 107. Using the application templateAs well as for the library, binaries can accept some prefix : check_PROGRAM : generate a binary for the unitary tests noinst_PROGRAM : generate a binary for local usage (won‘t be installed) Internal link flags should be given to the LDFLAGS one. That‘s include internalstatic library. External link flags should be given to the LDADD one. That‘s include all dependencieschecked by the PKG_CHECK_MODULE M4 macro
  108. 108. Using the application template Example of template used for a binary template :bin_PROGRAMS = foofoo_SOURCES = main.cfoo_SOURCES = main.cfoo_LDADD = @FLIBS@pkglib_LTLIBRARIES = libfoo.lalibfoo_la_SOURCES = bar.f baz.c zardoz.cclibfoo_la_LIBADD = $(FLIBS)
  109. 109. Using the application template  From Executable Binary to Process Memory Map : 0x0 Elf Header 0x400000 Code Code size Code 0x10000000 Padding Initialized Data Size Data (not 0) Initialized Data Data set to 0 (BSS) Statically Linked Heap Dyn Lib info Mono-thread DWARF EOF Debug Info Simple Case Process Stack Executable file Not loaded Memory Map in memory The header is not load in memory as defined in this picture because it gives information about the binary format;for instance it say at which memory address the code must be loaded.
  110. 110. Using the application template  The multi-threaded case : Multiple threads share the entire process address space CODE  Each thread has its own user space stack that is allocated when doing DATA pthread_create system call. If stack size is not given, a default value is used. BSS Be Careful: on x86 and NPTL POSIX thread implementation this means 8 Mb. This is the HEAP same value for default process stack size. Thread #1 Stack Always specify the stack size, . . . Try to kill the system created initial thread after creating your own init thread, Thread #1 Stack
  111. 111. Using the application templateExample of result for a processwith threads   Stack per thread.
  112. 112. Using the application template APPLICATION LAB
  113. 113. Using the application templateThe main goal for this lab is to:1.First, generate a foobin binary from a foobin.c source code.You will have to write a and a, generate a library foolib from a foolib.c source code.You will have to write a and a Makefile.am1.Third, merge the two and Makefile.amThe library should compile first as a static library then link withthe binary.
  114. 114. The config.h supportThe goal of this topic is to know how works the global config.h configuration header
  115. 115. The config.h header  Impact on the template :The AC_CONFIG_HEADERS([config.h]) M4 macro indicates that we will use a config.h header file.The generated header is included by your source code to pick up the results of the various configurationtests in the form of C preprocessor macro definitions. Every variable exported by the configure scriptthrough M4 macro (PKG_CHECK_MODULES(), AC_DEFINE(), AC_SUBST(), … ) will be set inside.The template file can also be generated automatically bythe autoheader tool. autoreconf will invoke autoheader when AC_CONFIG_HEADERS is usedin If multiple configuration headers are used, autoheader will always only generate thetemplate for the first one in the list.Example of usage in a template (…) dnl --------------------------------------- dnl Specify the internal toe_config.h dnl --------------------------------------- AC_CONFIG_HEADERS([inc/internal_config.h]) (..) That will generate a header called « internal_config.h » in the « inc » directory. Its content will include both all the boolean result of the internal check and also the custom checks made by Component itself.
  116. 116. The config.h header Impact on the template :lib_LTLIBRARIES = libtoe.lalibtoe_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.hlibtoe_la_CFLAGS = -I$(HEADER_DIR) $(LIBCONFIG_CFLAGS) $(LIBLOG_CFLAGS) -DLOG_NAME=TOE  Even if the config.h (here internal_config.h) is well include by the source code, this is important -DLOG_MASK_PRIO=LOG_PRIO_ALLlibtoe_la_LDFLAGS the Makefile in = -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) to specify it in order to include this dynamic file in the tarball generated by a make dist. -lpthread
  117. 117. The config.h header Config.h or not config.h that is the question…Without config.h : With config.h : Every flags will be provided to the compiler  The command line is more silent.over the command line (can be quite huge)  The config.h is the ID card of the build because Easy to manage with existent component it defines all the activator, values, used during the(don‘t need any modification for the header compilation.Import).  That need to import this header in all source The development process can check the code (.c, .cpp, .cxx, …) or within a top header. Thevariables either in this config.h header or inclusion should be secured like this :through the command line. #ifdef HAVE_CONFIG_H #include "config.h" #endif /* HAVE_CONFIG_H */
  118. 118. The config.h header GNU/MAKE LAB
  119. 119. The config.h headerThe main goal of this lab is to write one autotool projectwithout any config.h and another with that support.Compare the command line for the two build using « make v=1»
  120. 120. The config.h header More help about :
  121. 121. The silent/verbose supportThe goal of this topic is to know how works to manage the silent/verbose support
  122. 122. Managing silent/verbose supportWhen a big build is launch it can be nice to do not have too much tracesIn the console screen.The autotools can control the silent/verbose mode.If the silent mode is selected, no build or warning traces won‘t be written tostdio (err/out). Only errors will be displayed in detail and will stop the build process.
  123. 123. Managing silent/verbose supportOnce the silent/verbose mode have been choosen by the configure script, thisIs possible to override it thanks to the « V » parameter: Silent mode selected by the configure script: o Silent mode : make o Verbose mode : make V=1 Verbose mode selected by the configure script: o Silent mode : make V=0 o Verbose mode : make This is possible to tune more the silent/verbose mode: $ export LIBTOOLFLAGS "--silent“ $ make –s
  124. 124. Managing silent/verbose support SILENT/VERBOSE LAB
  125. 125. Managing silent/verbose support The main goal of this lab is to add a verbose support by adding the –enable-verbose.  The default state must be silent.
  126. 126. Managing dependencies with the pkg-config toolThe goal of this topic is to know how a pkgconfig file (.pc) are managed and how to usethe pkg-config tool.
  127. 127. The pkg-config tool The PKG-CONFIG tool (akaPaCKage CONFIGgurator)
  128. 128. The pkg-config toolThe pkg-config is a helper tool used when compiling applications and libraries.It helps you insert the correct compiler options rather than hard-coding values on where to findglib (or other libraries). It is language-agnostic, so it can be used for defining the location ofdocumentation tools, for instance.It works fine both with native and cross-compile environnement.The program is free software and licensed under the GPL version 2 or any later.pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OSX and Windows. It does not require anything but a reasonably well working C compiler and a Clibrary, but can use an installed glib if that is present. (A copy of glib 1.2.10 is shipped togetherwith pkg-config and this is sufficient for pkg-config to compile and work properly.)The first implementation was written in shell, by James Henstridge. Later, it was rewritten in Cby Havoc Pennington. It also grew an autoconf macro written by Tim Janik, later rewritten byScott James Remnant. The current maintainer is Tollef Fog Heen <>.The current release of pkg-config is version 0.25 (March 2011).
  129. 129. The pkg-config tool Variables for Installation Directories : For more information :
  130. 130. The pkg-config tool The autootols can make a fine tuning of the installation directories : --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/toe] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] --srcdir=DIR find the sources in DIR [configure dir or `..]Example : ./configure --prefix=/usr --srcdir=/tmp/tmp232123
  131. 131. The pkg-config tool Recent pkg-config tool version use several environment variables: