Hi Simon,
> I suppose the reason for this bug is that the gnulib stdint.h
> replacement is installed by libidn.
It is installed, but under a different name, namely idn-int.h!
> However, I believe we have discussed this mode of operation before, and
> there hasn't been any problems until now.
The widespread use of #include_next is quite recent indeed.
> Perhaps #include_next is simply not reliable to use in generated *.h
> files?
Although I cannot reproduce the original problem (tried gcc 3.3.1 and 4.2.0),
it is perfectly understandable that a compiler stops working when it
encounters
#include_next <stdint.h>
in a file called idn-int.h.
Since the original poster already reported that #include instead of
#include_next works fine, I would suggest that you try this:
--- lib/Makefile.am.bak 2007-05-31 12:31:00.000000000 +0200
+++ lib/Makefile.am 2007-06-21 00:40:53.000000000 +0200
@@ -37,7 +37,7 @@
idn-int.h:
if test -n "$(STDINT_H)"; then \
- cp gl/stdint.h idn-int.h; \
+ sed -e s/include_next/include/ gl/stdint.h > idn-int.h; \
else \
echo '#include <stdint.h>' > idn-int.h; \
fi
If that works out, we can document it in gnulib's documentation.
Bruno
