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

I installed the patch. /Simon Simon Josefsson <[EMAIL PROTECTED]> writes: > How about this patch? I'm not sure where a good place to add this is, > or whether it should use a @subsection or something. But the important > thing is to say something similar somewhere. > > /Simon > > --- stdint.te

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

Simon Josefsson <[EMAIL PROTECTED]> writes: >> --- lib/Makefile.am.bak 2007-05-31 12:31:00.0 +0200 >> +++ lib/Makefile.am 2007-06-21 00:40:53.0 +0200 >> @@ -37,7 +37,7 @@ >> >> idn-int.h: >> if test -n "$(STDINT_H)"; then \ >> -cp gl/stdint.h idn-int.h; \

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

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

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

Paul Eggert wrote: > This includes ///opt/sun12/sunstudio12/prod/include/cc/time.h, which starts > off this way: > > #include_next > > which resolves to "./time.h" so we are in a loop. Thanks for explaining. This is effectively the same situation as with DEC cc (see

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

Bruno Haible <[EMAIL PROTECTED]> writes: > Thanks for your patch. But how does it solve the original problem? Only > because it enables include_next for compilers that support it, and Sun > Studio cc happens to be one of these compilers, right? That's the basic idea, yes. I had been planning to

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

> Thanks for your patch. But how does it solve the original problem? Only > because it enables include_next for compilers that support it, and Sun > Studio cc happens to be one of these compilers, right? I think, (but don't know for sure as I'm not on a Sun), that the problem is that Sun's used

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

Hi Paul, Thanks for your patch. But how does it solve the original problem? Only because it enables include_next for compilers that support it, and Sun Studio cc happens to be one of these compilers, right? > That compiler supports #include_next but is not GCC. > It gets into recursive inclusion

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

Bruno Haible <[EMAIL PROTECTED]> writes: > Although I cannot reproduce the original problem (tried gcc 3.3.1 and 4.2.0), I ran into a similar problem a couple of days ago with Sun Studio 12 on GNU/Linux. That compiler supports #include_next but is not GCC. It gets into recursive inclusion loops,

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

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. Th

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

Simon Josefsson <[EMAIL PROTECTED]> writes: > Perhaps #include_next is simply not reliable to use in generated *.h > files? We need to handle it better, yes. I'll look into it.

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

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/