Next: Systemology Prev: Running the Linker Up: Writing Tests
6.6 Checking Runtime Behavior
Sometimes you need to find out how a system performs at runtime, such
as whether a given function has a certain capability or bug. If you
can, make such checks when your program runs instead of when it is
configured. You can check for things like the machine's endianness when
your program initializes itself.
If you really need to test for a runtime behavior while configuring,
you can write a test program to determine the result, and compile and
run it using `AC_RUN_IFELSE'. Avoid running test programs if possible,
because this prevents people from configuring your package for
-- Macro: AC_RUN_IFELSE (INPUT, [ACTION-IF-TRUE], [ACTION-IF-FALSE],
If PROGRAM compiles and links successfully and returns an exit
status of 0 when executed, run shell commands ACTION-IF-TRUE.
Otherwise, run shell commands ACTION-IF-FALSE.
The INPUT can be made by `AC_LANG_PROGRAM' and friends. `LDFLAGS'
and `LIBS' are used for linking, in addition to the compilation
flags of the current language (Note: Language Choice).
If the compiler being used does not produce executables that run
on the system where `configure' is being run, then the test
program is not run. If the optional shell commands
ACTION-IF-CROSS-COMPILING are given, they are run instead.
Otherwise, `configure' prints an error message and exits.
In the ACTION-IF-FALSE section, the failing exit status is
available in the shell variable `$?'. This exit status might be
that of a failed compilation, or it might be that of a failed
It is customary to report unexpected failures with
Try to provide a pessimistic default value to use when
cross-compiling makes runtime tests impossible. You do this by passing
the optional last argument to `AC_RUN_IFELSE'. `autoconf' prints a
warning message when creating `configure' each time it encounters a
call to `AC_RUN_IFELSE' with no ACTION-IF-CROSS-COMPILING argument
given. You may ignore the warning, though users cannot configure your
package for cross-compiling. A few of the macros distributed with
Autoconf produce this warning message.
To configure for cross-compiling you can also choose a value for
those parameters based on the canonical system name (Note: Manual
Configuration). Alternatively, set up a test results cache file with
the correct values for the host system (Note: Caching Results).
To provide a default for calls of `AC_RUN_IFELSE' that are embedded
in other macros, including a few of the ones that come with Autoconf,
you can test whether the shell variable `cross_compiling' is set to
`yes', and then use an alternate method to get the results instead of
calling the macros.
It is also permissible to temporarily assign to `cross_compiling' in
order to force tests to behave as though they are in a
cross-compilation environment, particularly since this provides a way to
test your ACTION-IF-CROSS-COMPILING even when you are not using a
# We temporarily set cross-compile mode to force AC_COMPUTE_INT
# to use the slow link-only method
A C or C++ runtime test should be portable. Note: Portable C and
Erlang tests must exit themselves the Erlang VM by calling the
`halt/1' function: the given status code is used to determine the
success of the test (status is `0') or its failure (status is different
than `0'), as explained above. It must be noted that data output
through the standard output (e.g., using `io:format/2') may be
truncated when halting the VM. Therefore, if a test must output
configuration information, it is recommended to create and to output
data into the temporary file named `conftest.out', using the functions
of module `file'. The `conftest.out' file is automatically deleted by
the `AC_RUN_IFELSE' macro. For instance, a simplified implementation
of Autoconf's `AC_ERLANG_SUBST_LIB_DIR' macro is:
AC_INIT([LibdirTest], [1.0], [firstname.lastname@example.org])
[echo "code:lib_dir() returned: `cat conftest.out`"],
[AC_MSG_FAILURE([test Erlang program execution failed])])
automatically generated by info2www