Remko van der Vossen <[EMAIL PROTECTED]> 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
