confirure incorrectly 'detects' stdbool.h and sets HAVE_STDBOOL in .../source3/include/config.h.
I had to get rid of it manualy:
diff -u ./source3/include/config.h.orig ./source3/include/config.h
--- ./source3/include/config.h.orig 2010-05-26 09:28:24.000000000 -0500
+++ ./source3/include/config.h 2010-05-26 09:38:35.000000000 -0500
@@ -2116,7 +2116,9 @@
#define HAVE_STDARG_H 1
/* Define to 1 if you have the <stdbool.h> header file. */
+#ifndef __TANDEM /* wrongly recognized? */
#define HAVE_STDBOOL_H 1
/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1
But I'm well aware thai this is not the proper fix...
Forget about it, I must have made some mistake, as an attempt to reproduce this failed miserably, 'configure' does detect the absence of stdbool.h and reflects that in config.h.
Guess I missee a 'make clean' between two 'configure' runs and the 2nd one deteted stdbool.h in ...lib/replace.
See also bug 7461, which I believe can also get closed (I'm verifying this at the moment).
do we actually require to run a make clean before each configure?
Shouldn't libreplace's configure see that the found stdbool.h is its own one and not throw its that one away after it found it? :-)
Well, I was only guessing what might have gone wrong. I couldn't reproduce it later. That's why I closed the bug.
But if you have ideas what went wrong and how to fix, I'd not be agaist it...
this is a problem we see on other machines, too. I also stumbed over it on IRIX and another machine recently. Metze or Jelmer - do you have an idea how to easily limit the search for header files to the system include directories only and prevent that libreplace finds its own generated header files?
I guess the issue is that we shouldn't have lib/replace in the include paths during configure - we weren't doing so in the past at least. Is there any reason why we need to do so now?