Eric Blake wrote:
> But it looks like your patch didn't quite fix things either - by moving
> the lone call to AC_LIBOBJ([fpurge]) inside the ac_cv_func_fpurge = yes
> block, you are failing to compile fpurge.c when __fpurge exists but not
> fpurge.
This situation occurs precisely on glibc systems, and I did not see
compilation or test failures on Linux. That's because the module description
still causes fpurge.c to be compiled always...
I'm applying this fixup.
2009-08-16 Bruno Haible <br...@clisp.org>
* modules/fpurge (Makefile.am): Don't compile fpurge.c always.
* m4/fpurge.m4 (gl_FUNC_FPURGE): But do compile it if the system does
not have fpurge.
Reported by Eric Blake.
--- m4/fpurge.m4.orig 2009-08-16 17:31:49.000000000 +0200
+++ m4/fpurge.m4 2009-08-16 17:30:50.000000000 +0200
@@ -32,10 +32,12 @@
return 0;])],
[gl_cv_func_fpurge_works=yes], [gl_cv_func_fpurge_works=no],
[gl_cv_func_fpurge_works='guessing no'])])
- if test "x$gl_cv_func_fpurge_works" != xyes; then
- REPLACE_FPURGE=1
- AC_LIBOBJ([fpurge])
- fi
+ fi
+ if test "x$ac_cv_func_fpurge" = xyes && test "x$gl_cv_func_fpurge_works" =
xyes; then
+ : # OK, fpurge exists and works.
+ else
+ REPLACE_FPURGE=1
+ AC_LIBOBJ([fpurge])
fi
if test "x$ac_cv_have_decl_fpurge" = xno; then
HAVE_DECL_FPURGE=0
--- modules/fpurge.orig 2009-08-16 17:31:49.000000000 +0200
+++ modules/fpurge 2009-08-16 17:29:40.000000000 +0200
@@ -14,7 +14,6 @@
gl_STDIO_MODULE_INDICATOR([fpurge])
Makefile.am:
-lib_SOURCES += fpurge.c
Include:
<stdio.h>
