What is the correct position of "lib/clang/16/include" in the include path sequence on Windows?

Clang Frontend Using Clang
1

I am using clang-16 on Linux to cross-compile for Windows with winsdk 10.0.22000 and ucrt. I am using “/winsdkdir” and “/vctoolsdir” as command line options for clang-cl to add the winsdk and ucrt files to the include and the library paths.

By default Clang uses the builtin “lib/clang/16/include” directory as the first include path searched, but in my configuration that results in an issue. The following include files are available in both the buitlin clang directory and in the SDK/VCTOOLS directories:

winsdk/crt/include/iso646.h
winsdk/crt/include/vadefs.h
winsdk/crt/include/mm3dnow.h
winsdk/crt/include/tmmintrin.h
winsdk/sdk/include/10.0.22000/ucrt/float.h
winsdk/crt/include/tmmintrin.h
winsdk/crt/include/xmmintrin.h
winsdk/crt/include/smmintrin.h
winsdk/crt/include/pmmintrin.h
winsdk/crt/include/mmintrin.h
winsdk/crt/include/emmintrin.h
winsdk/crt/include/immintrin.h
winsdk/crt/include/limits.h
winsdk/crt/include/xmmintrin.h
winsdk/crt/include/ammintrin.h
winsdk/crt/include/arm_neon.h
winsdk/crt/include/smmintrin.h
winsdk/crt/include/omp.h
winsdk/crt/include/pmmintrin.h
winsdk/crt/include/mmintrin.h
winsdk/crt/include/emmintrin.h
winsdk/crt/include/stdbool.h
winsdk/sdk/include/10.0.22000/ucrt/complex.h
winsdk/sdk/include/10.0.22000/ucrt/math.h
winsdk/sdk/include/10.0.22000/ucrt/stddef.h
winsdk/crt/include/stdarg.h
winsdk/crt/include/arm64intr.h
winsdk/crt/include/varargs.h
winsdk/crt/include/armintr.h
winsdk/crt/include/stdint.h
winsdk/crt/include/intrin.h
winsdk/crt/include/immintrin.h
winsdk/sdk/include/10.0.22000/ucrt/inttypes.h
winsdk/crt/include/nmmintrin.h
winsdk/crt/include/wmmintrin.h

Should I prefer the files from the Clang directory or those from Winsdk / ucrt?

I am asking because I have some macro redefinition issue because by default Clang prefers its builtin “immintrin.h” file while compiling liblzma instead of the Microsoft supplied one. Changing the include path order would be easy, but I would like to know whether it is correct to prefer for instance the Microsoft “stdint.h” over the Clnag-provided one.

2

As I responded in your other thread. You, most of the time want to use the one that’s shipped with your version of the compiler to ensure compatibility. The same applies to Windows cross-compiles, but I am 100% sure since I haven’t used such a configuration.

We are using clang-cl natively on windows to build our applications and we don’t change the include order, and I just confirmed that clang’s resource dir is coming first so I am now 99% sure the same should apply when cross-compiling.

3

Thanks, this makes sense. Your claim is further supported by the llvm-dev mailing list.

My macro redefinition issue was caused by myself, because I have used -nobuiltininc and adding the clang builtin include path via /I, instead of using -resource-dir as you have proposed in the other thread.