Date: Fri, 21 Jul 2000 11:47:24 -0700
From: Greg McGary <[EMAIL PROTECTED]>
It seems to me that the simple solution is teach AC_CHECK_FUNCS (and
others?) which library functions have pointers in their signatures,
Autoconf shouldn't keep track of which functions have pointers in
their signatures. There are too many of them, with too many variants
on different hosts, and the variants mutate too rapidly.
Furthermore, autoconf 2.13 AC_CHECK_FUNC is obsolete these days, as
C99 requires that functions must be declared before used. So we need
to do something about this anyway, and perhaps we can kill two birds
with one stone.
So how about this solution instead? Define a new macro,
AC_CHECK_FUNCTION say, where the caller specifies not only the
function name but also the headers that declare it.
For example, AC_CHECK_FUNCTION(open, (sys/types.h, sys/stat.h,
fcntl.h)) would first check for the existence of those three headers
and then attempt to compile and link the following program:
#if HAVE_SYS_TYPES_H
# include <sys/types.h>
#endif
#if HAVE_SYS_STAT_H
# include <sys/stat.h>
#endif
#if HAVE_FCNTL_H
# include <fcntl.h>
#endif
main () { return !open; }
We can keep AC_CHECK_FUNC around for backward compatibility, and
encourage people to switch to AC_CHECK_FUNCTION.
In order to prevent accidentally mixing BP and non-BP functions,
gcc prepends "__BP_" to the name of every function that has a
pointer in its arg-type/return-type signature.
I don't see how this can work in general. A function can access data
via other means, e.g. external pointers or casting its arguments to
pointers. So even if its signature contains no pointers, a function
can still be incompatible with code compiled with the other regime.
