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

[Eric Blake-1]

> 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 <unistd.h> used an include_next, which finds the gnulib
<unistd.h> first in the path.  The problem is that when include_next is
both supported AND is in use by system headers, then gnulib MUST use
include_next to pull in the system header, or else the system header
will try to recursively pull in the gnulib header, which leads to the
recursion problem.

Which is why Paul's fix works - it switches the Sun case from
absolute includes to include_next.

> Can't the same error still occur with other compilers, that don't support
> include_next?

If my above analysis is right, then no.  If a compiler does not support
include_next, then system headers won't try to pull in a file by
the same name, which means they won't recurse back into the
gnulib header.  Also, the problem won't exist even on compilers
with include_next, so long as system headers didn't use include_next.

-- 
Eric Blake

-- 
View this message in context: 
http://www.nabble.com/Re%3A-problem-with--include_next%3Cstdint.h%3E-in--usr-include-idn-int.h-tf3951944.html#a11234306
Sent from the Gnulib mailing list archive at Nabble.com.