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

[Simon Josefsson]

Remko van der Vossen <address@hidden> writes:

> Hello everyone,
>
> I have a problem with using libidn;
>
> I tried to compile mutt (1.5.9 and CVS) with libidn support, but got the
> following error in both cases:
>
> gcc -DPKGDATADIR=\"/usr/share/mutt\" -DSYSCONFDIR=\"/etc\"
> -DBINDIR=\"/usr/bin\" -DMUTTLOCALEDIR=\"/usr/share/locale\"
> -DHAVE_CONFIG_H=1 -I.  -I. -I. -I./imap  -Iintl -I./intl -I/usr/include
> -Wall -pedantic -O -march=pentium3 -pipe -O3 -g -MT addrbook.o -MD -MP
> -MF .deps/addrbook.Tpo -c -o addrbook.o addrbook.c
> In file included from /usr/include/idna.h:31,
>                  from mutt_idna.h:26,
>                  from addrbook.c:28:
> /usr/include/idn-int.h:48:27: error: no include path in which to search
> for stdint.h
>
> /usr/include/idn-int.h uses a #include_next<stdint.h> which fails
> because the include path past /usr/include is empty as is evident from
> the gcc call.
>
> I do not understand why idn-int.h uses #include_next instead of
> #include. Is this a bug, or is there something wrong in the way mutt
> uses libidn, or something in the layour of my include files?
>
> When I change the #include_next<stdint.h> to an #include<stdint.h> I can
> compile mutt without problems.
>
> Please see: http://bugs.sourcemage.org/show_bug.cgi?id=13857

Hi!  Thanks for the report.  The stdint.h replacements is from gnulib,
so I'm forwarding this bug to the bug-gnulib mailing list.  It is most
likely not a mutt problem, but rather a bug in that particular file.

I suppose the reason for this bug is that the gnulib stdint.h
replacement is installed by libidn.  However, I believe we have
discussed this mode of operation before, and there hasn't been any
problems until now.

Any ideas?

Perhaps #include_next is simply not reliable to use in generated *.h
files?

/Simon