| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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).
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.1 Language Choice, for more information
about selecting the language for checks.)
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.
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.
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.
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) |
AC_LIBOBJ replacement files are to be found in
directory, a relative path starting from the top level of the
source tree. The replacement directory defaults to `.', the top
level directory, and the most typical value is `lib', corresponding
to `AC_CONFIG_LIBOBJ_DIR(lib)'.
configure might need to know the replacement directory for the
following reasons: (i) some checks use the replacement files, (ii) some
macros bypass broken system headers by installing links to the
replacement headers, etc.
It is common to merely check for the existence of a function, and ask
for its AC_LIBOBJ replacement if missing. The following macro is
a convenient shorthand.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |