Re: problem with #include_next<stdint.h> in /usr/include/idn-int.h

[Simon Josefsson]

Bruno Haible <address@hidden> 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