llvmbot
commented
8 years ago GCC's builtin headers should not be in your heater search path at all. Are you explicitly specifying them, or is clang's driver erroneously adding them for you?
They are in the builtin include search path:
$ clang -v -c tdirent.c clang version 3.7.1 (tags/RELEASE_371/final) Target: i686-pc-windows-cygnus Thread model: posix "/usr/bin/clang-3.7" -cc1 -triple i686-pc-windows-cygnus -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name tdirent.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -v -dwarf-column-info -coverage-file /home/HBB/tmp/tdirent.c -resource-dir /usr/bin/../lib/clang/3.7.1 -fdebug-compilation-dir /home/HBB/tmp -ferror-limit 19 -fmessage-length 149 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o tdirent.o -x c tdirent.c clang -cc1 version 3.7.1 based upon LLVM 3.7.1 default target i686-pc-windows-cygnus ignoring nonexistent directory "/usr/local/include"
include "..." search starts here:
include <...> search starts here:
/usr/bin/../lib/clang/3.7.1/include /usr/lib/gcc/i686-pc-cygwin/5.3.0/include /usr/include /usr/include/w32api End of search list.
ec04fc15-fa35-46f2-80e1-5d271f2ef708
Extended Description
The issue described in Bug ID 6379 about 6 years ago is still (or again?) present in version 3.7.1 on Cygwin. I'd try to re-open that one, but since it was for Linux, and this isn't, I'm filing a new one.
A source containing just
include
fails to compile using clang on current Cygwin, because it doesn't find NAME_MAX. The problem is, just as described in 6379, that this mechanism in clang's:
/ The system's limits.h may, in turn, try to #include_next GCC's limits.h. Avert this #include_next madness. /
if defined GNUC && !defined _GCC_LIMITSH
define _GCC_LIMITSH
endif
causes the subsequent #include_next, which pulls in GCC's version, to expand to nothing. Unfortunately, this mean the actual system is never included, because that would have been done from inside GCC's one. Here's a preprocessed source excerpt of how it's supposed to be (indented by hand, for clarity):
1 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 1 3 4
39 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 3 4
1 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/limits.h" 1 3 4
34 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/limits.h" 3 4
1 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/syslimits.h" 1 3 4
8 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/syslimits.h" 2 3 4
35 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/limits.h" 2 3 4
40 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 2 3 4
17 "/usr/include/sys/dirent.h" 2 3 4
With the above code snippet active, this ends at gcc's, so it never reaches /usr/include/limits.h, and thus fails to find NAME_MAX defined there.
As I see it, that "Avert ... madness" mechanism is a badly planned hack which does exactly the wrong thing on any platform where GCC is the primary compiler (Linux, Cygwin, MinGW, ...).
As to Bug 6379, I have no idea how that could have been marked "closed", given that the problematic code sequence is still present today, the proposed fix was never applied, nor could the actual issue be considered "fixed".