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