Bruno Haible <[EMAIL PROTECTED]> writes: > 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!
Hi Bruno. Ah. >> 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: We're testing this now, I'm awaiting Remko's response on whether it works. > --- 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. Yes, I'll propose a patch. Others may want to use POSIX uint*_t types in their public header files too, and the only way to do that portably appears to install your own stdint.h replacement, so documenting that this approach works would be good. /Simon
