Next: , Previous: , Up: Installation   [Contents][Index]

2.1 configure

configure is a Bourne-shell script that analyzes your system’s capabilities (compiler features, library and header-file availability, function and datatype availability, linker flags for various options, etc.) and custom-generates a Makefile and miscellaneous other files. configure accepts a variety of command-line options. ./configure --help lists all of the options. The following are some of the more useful ones:


coNCePTuaL normally installs both static and dynamic libraries. While dynamic libraries have a number of advantages they do need to be installed on all nodes that run the compiled coNCePTuaL programs. If global installation is not convenient/feasible, --disable-shared can be used to force static linking of executables. Note, however, that , the Python interface to the coNCePTuaL run-time library, needs to be built as a shared object so that it can be loaded dynamically into a running Python interpreter. --disable-shared inhibits the compilation and installation of .


make install normally installs coNCePTuaL into the /usr/local directory. The --prefix option instructs configure to write a Makefile with a different installation directory. For example, --prefix=/local/encap/conceptual-1.5.1 will cause coNCePTuaL’s files to be installed in /local/encap/conceptual-1.5.1/bin, /local/encap/conceptual-1.5.1/include, etc.


In some circumstances it may be necessary to prevent coNCePTuaL from using certain libraries even when ./configure detects them and believes them to be usable. The --with-ignored-libs configuration option forces ./configure to ignore one or more specified libraries. Only the base name of each library should be used; omit directory names, the ‘lib’ prefix (on Unix-like systems), and the file suffix. For example, to disable the use of /usr/local/lib/libpapi.a you should specify --with-ignored-libs=papi.


./configure detects automatically if your system provides a working fork() function. However, it cannot detect if fork() correctly spawns a child process but corrupts the parent’s memory map while doing so, as is the case when using some InfiniBand software stacks. The --without-fork option inhibits the use of fork() and well as functions that implicitly invoke fork() such as system() and popen() .


The coNCePTuaL run-time library is able to use any of a variety of platform-specific microsecond timers to take timing measurements. (See Time-related functions, for a complete list.) The --with-gettimeofday option forces the run-time library to utilize instead the generic C gettimeofday() function. This can be useful in the rare, but not impossible, case that a quirk in some particular platform misleads one of coNCePTuaL’s other timers. The validatetimer utility (see Validating the coNCePTuaL timer) can help determine whether --with-gettimeofday is necessary.


On some systems the most accurate timer available is provided by the MPI_Wtime() function in the MPI library. The --with-mpi-wtime option forces the run-time library to measure elapsed time using MPI_Wtime() instead of any of the other available timers. (See Time-related functions, for a complete list). The ramifications of --with-mpi-wtime are threefold:

  1. The option requires that you link all coNCePTuaL programs against an MPI library and run them like any other MPI program. (You may need to set CPPFLAGS , LIBS , LDFLAGS , or some of the other command-line variables described below.)
  2. MPI_Wtime() may be less accurate than some of the other timers available to coNCePTuaL. In many MPI implementations, MPI_Wtime() simply invokes gettimeofday(), for instance.
  3. Although this is a rare problem, it may not be safe to invoke MPI_Wtime() without first invoking MPI_Init(). Fortunately, proper juxtaposition of the two functions is not a concern for the coNCePTuaL C+ MPI backend (see The c_mpi backend), which ensures that MPI_Init() is invoked before MPI_Wtime().

In short, you should specify --with-mpi-wtime only if you have good reason to believe that MPI_Wtime() is likely to produce the most accurate timing measurements on your system.

CC=C compiler

configure automatically searches for a C compiler to use. To override its selection, assign a value to CC on the command line. For example, ./configure CC=ecc will cause coNCePTuaL to be built with ecc.

CFLAGS=C compiler flags
LDFLAGS=linker flags
CPPFLAGS=C preprocessor flags
LIBS=extra libraries

Like CC , these variables override the values determined automatically by configure. As an illustration, ./configure CPPFLAGS="-DSPECIAL -I/home/pakin/include/special -I." CFLAGS="-O3 -g -Wall -W" LDFLAGS=--static LIBS="-lz /usr/lib/libstuff.a" assigns values to all four variables.

MPICC=C compiler
MPICPPFLAGS=C preprocessor flags
MPILDFLAGS=extra linker flags
MPILIBS=extra libraries

These variables are analagous to CC , CPPFLAGS , LDFLAGS , and LIBS , respectively. The difference is that they are not used to build the coNCePTuaL run-time library but rather to build user programs targeted to the C+ MPI compiler backend. For example, if your MPI installation lacks an mpicc script, you may need to specify extra header files and libraries explicitly: ./configure MPICPPFLAGS="-I/usr/lib/mpi/include" MPILIBS="-lmpich" .

As a rather complex illustration of how some of the preceding options (as well as a few mentioned by ./configure --help) might be combined, the following is how coNCePTuaL was once configured to cross-compile from a Linux/PowerPC build machine to a prototype of the BlueGene/L supercomputer (containing, at the time, 2048 embedded PowerPC processors, each executing a minimal run-time system, BLRTS). IBM’s xlc compiler was accessed via a wrapper script called mpcc.

./configure CFLAGS="-g -O -qmaxmem=64000" CC=/bgl/local/bin/mpcc CPP="gcc -E" --host=powerpc-ibm-linux-gnu --build=powerpc-unknown-linux-gnu --with-alignment=8 --with-gettimeofday --prefix=/bgl/bgguest/LANL/ncptl MPICC=/bgl/local/bin/mpcc CPPFLAGS=-I/BlueLight/floor/bglsys/include

It’s always best to specify environment variables as arguments to ./configure because the configure script writes its entire command line as a comment to config.log and as a shell command to config.status to enable re-running ./configure with exactly the same parameters.

When ./configure finishes running it outputs a list of the warning messages that were issued during the run. If no warnings were issued, ./configure will output ‘Configuration completed without any errors or warnings.’. Warnings are also written to config.log and can therefore be redisplayed at any time by executing a shell command such as grep WARNING config.log.

Next: , Previous: , Up: Installation   [Contents][Index]

Scott Pakin,