Re: Problem with AC_CHECK_FUNCS() and new versions of g++

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 08 Dec 2000 14:34:35 +0100
> 
> | #include <assert.h>
> | /* Override any gcc2 internal prototype to avoid an error.  */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | /* We use char because int might match the return type of a gcc2
> |    builtin and then its argument prototype would still apply.  */
> | char mkdir ();
> | char (*f) ();
> 
> BTW, I never quite understood this comment.  Could someone explain it
> to me?
> first prototype it sees is compatible?

This comment highlights a confusing botch in autoconf.

Here's an example of the problem.  Consider the following C program,
generated by AC_TRY_LINK_FUNC(abs):

  int abs ();
  main () { return abs (); }

This program does not conform to the C standard, as the C standard
does not let you redefine builtin C functions.  So GCC warns about it.

To disable this warning, AC_TRY_LINK_FUNC does this instead:

  char abs ();
  int main () { return abs (); }

This program doesn't conform to the C standard, either!  But GCC does
not warn about it so it's good enough for GCC users.

The real problem is that the autoconf AC_TRY_LINK_FUNC macro is
unportable, and is using the wrong assumptions.  There is no reliable
way in general to see whether you can link a C function without
knowing the function's prototype.  AC_TRY_LINK_FUNC is a hack that
sort of works, most of the time, but does not work in general.

AC_CHECK_FUNC, AC_TRY_LINK_FUNC, etc. should have arguments specifying
the function prototype, and should generate output that looks like
this instead:

  ... define PROTO in the usual way ...
  int abs PROTO ((int));
  int (*p) PROTO ((int)) = abs;

It's too late to fix this now for the next autoconf release, but
this problem will fester until fixed.


> Am I understanding that if __stub_foo exists, it means that foo
> doesn't really exist?

No, it means that foo exists, but if invoked foo will always fail with
ENOSYS.