| Marketplace
|
 |
|
5.5.3 Generic Function Checks
These macros are used to find functions not covered by the "particular"
test macros. If the functions might be in libraries other than the
default C library, first call AC_CHECK_LIB for those libraries.
If you need to check the behavior of a function as well as find out
whether it is present, you have to write your own test for
it (see section 6. Writing Tests).
- Macro: AC_CHECK_FUNC (function, [action-if-found], [action-if-not-found])
-
If C function function is available, run shell commands
action-if-found, otherwise action-if-not-found. If you just
want to define a symbol if the function is available, consider using
AC_CHECK_FUNCS instead. This macro checks for functions with C
linkage even when AC_LANG(C++) has been called, since C is more
standardized than C++. (see section 6.7 Language Choice, for more information
about selecting the language for checks.)
- Macro: AC_CHECK_FUNCS (function..., [action-if-found], [action-if-not-found])
-
For each function in the whitespace-separated argument list,
define
HAVE_function (in all capitals) if it is available.
If action-if-found is given, it is additional shell code to
execute when one of the functions is found. You can give it a value of
`break' to break out of the loop on the first match. If
action-if-not-found is given, it is executed when one of the
functions is not found.
Autoconf follows a philosophy that was formed over the years by those
who have struggled for portability: isolate the portability issues in
specific files, and then program as if you were in a POSIX
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
Use the first three of the following macros to specify a function to be
replaced, and the last one (AC_REPLACE_FUNCS) to check for and
replace the function if needed.
- Macro: AC_LIBOBJ (function)
-
Specify that `function.c' must be included in the executables
to replace a missing or broken implementation of function.
Technically, it adds `function.$ac_objext' to the output
variable LIBOBJS and calls AC_LIBSOURCE for
`function.c'. You should not directly change LIBOBJS,
since this is not traceable.
- Macro: AC_LIBSOURCE (file)
-
Specify that file might be needed to compile the project. If you
need to know what files might be needed by a `configure.ac', you
should trace
AC_LIBSOURCE. file must be a literal.
This macro is called automatically from AC_LIBOBJ, but you must
call it explicitly if you pass a shell variable to AC_LIBOBJ. In
that case, since shell variables cannot be traced statically, you must
pass to AC_LIBSOURCE any possible files that the shell variable
might cause AC_LIBOBJ to need. For example, if you want to pass
a variable $foo_or_bar to AC_LIBOBJ that holds either
"foo" or "bar", you should do:
| | AC_LIBSOURCE(foo.c)
AC_LIBSOURCE(bar.c)
AC_LIBOBJ($foo_or_bar)
|
There is usually a way to avoid this, however, and you are encouraged to
simply call AC_LIBOBJ with literal arguments.
Note that this macro replaces the obsolete AC_LIBOBJ_DECL, with
slightly different semantics: the old macro took the function name,
e.g. foo, as its argument rather than the file name.
- Macro: AC_LIBSOURCES (files)
-
Like
AC_LIBSOURCE, but accepts one or more files in a
comma-separated M4 list. Thus, the above example might be rewritten:
| | AC_LIBSOURCES([foo.c, bar.c])
AC_LIBOBJ($foo_or_bar)
|
- Macro: AC_REPLACE_FUNCS (function...)
-
Like
AC_CHECK_FUNCS, but uses `AC_LIBOBJ(function)' as
action-if-not-found. You can declare your replacement function by
enclosing the prototype in `#if !HAVE_function'. If the
system has the function, it probably declares it in a header file you
should be including, so you shouldn't redeclare it lest your declaration
conflict.
|
 |