fatal error: 'limits.h' file not found

[mihails-strasuns-sociomantic]

With latest dstep master trying to convert https://github.com/protobuf-c/protobuf-c/blob/master/protobuf-c/protobuf-c.h results in this:

/usr/include/limits.h:123:16: fatal error: 'limits.h' file not found

[jacob-carlborg]

Is it the embedded limits.h it can't find?

[mihails-strasuns]

Seems so, but I am not sure how to debug the lookup. I have noticed limits.h is missing in this list https://github.com/jacob-carlborg/dstep/blob/master/clang/Compiler.d#L38 and trying adding it but with no success.

[jacob-carlborg]

Hmm, it definitely should be in that list.

[jacob-carlborg]

Which version of libclang are you using? How does your /usr/include/limits.h look like, for the line it complains about? I cannot reproduce this on macOS, but I'm pretty sure that /usr/include/limits.h is different, I assume you're on Arch Linux?

[mihails-strasuns]

Checked on both Arch Linux and Ubuntu, clang versions 3.6 and 3.8

Relevant lines:

/* Get the compiler's limits.h, which defines almost all the ISO constants.

    We put this #include_next outside the double inclusion check because
    it should be possible to include this file more than once and still get
    the definitions from gcc's header.  */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
/* `_GCC_LIMITS_H_' is what GCC's file defines.  */
# include_next <limits.h>
#endif

The way I understand it, problem comes from the fact it still looks in /usr/include/ for limits.h despite it is compiled in resources. And finds the one from GCC which causes the trouble.

[jacob-carlborg]

I think the issue is the include_next. I slightly modified DStep to include the limits.h and the virtual include path. My include paths look like this:

#include "..." search starts here:
#include <...> search starts here:
 /4421172 # virtual include path added by DStep
 /usr/local/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)

It finds limits.h in /usr/include then include_next tells the compiler to look for the header file in the next include path, which is supposed to be the compiler built-in. Although I don't know why it's doesn't find it in the virtual include path /4421172.

[jacob-carlborg]

BTW, my small test doesn't work using regular Clang either, for some reason.

[jacob-carlborg]

I tried in Ubuntu, the issue is that the virtual include path is missing. This function [1] is never used. Adding that to the list of include paths seems to fix the problem.

[1] https://github.com/jacob-carlborg/dstep/blob/master/clang/Compiler.d#L41

[jacob-carlborg]

It's a regression introduced by: 3ed7e54.

[mihails-strasuns]

Aha, I see now. Thanks for the information, I'll submit a fix tomorrow!