KhronosGroup / KhronosGroup/SPIRV-Tools
Windows Clang build requires PATH to find the C++ runtime
- Dominant language
- C++
- Stars
- 1.4k
- Forks
- 709
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 28
Description
Spawned by https://github.com/android/ndk/issues/1464#issuecomment-791357898
> On Windows, the CMake files try to link these executables' STL stuff statically. glslc.exe is configured using the [shaderc_default_compile_options](https://android.googlesource.com/platform/external/shaderc/shaderc/+/9c602842f9386ec12d53b31fbd70f1d596775f58/cmake/utils.cmake#59) CMake function. The logic here is to add -static -static-libgcc -static-libstdc++ if NOT "${MSVC}" and WIN32. This works, and glslc.exe has no dynamic STL/libgcc dependency.
> spirv-tools, on the other hand uses the [spvtools_default_compile_options](https://android.googlesource.com/platform/external/shaderc/spirv-tools/+/47df6daa2cea78e737c171aa9dda5fdd5353f87a/CMakeLists.txt#175) CMake function. This function tries to add the same three options, when ${CMAKE_SYSTEM_NAME} MATCHES "Windows" and ${CMAKE_CXX_COMPILER_ID} MATCHES "GNU" are both true. On r22, it only adds the first option -static, because CMake syntax requires quoting the whole thing. (Unless CMake stumbles on the -, I think it's setting a target property named -static-libgcc to the value -static-libstdc++.) With the current NDK master, it doesn't run because CMAKE_CXX_COMPILER_ID changed from GNU to Clang.
> My guess is that the right logic is: WIN32 AND NOT MSVC.
This issue tracks updating the conditions for static linking the C++ runtime to also cover the Clang build.
Contributor guide
Assessment
This issue has not been assessed yet.