# C++ interoperability is broken (Windows platform) **URL:** \ **Category:** Using Swift\ **Tags:** windows, cxx-interop\ **Created:** [June 14, 2024, 2:19am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462 "2024-06-14T02:19:32Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![dima\_kozhinov](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dima\_kozhinov](https://forums.swift.org/u/dima_kozhinov)\ **Post date:** [June 14, 2024, 2:19am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/1 "2024-06-14T02:19:32Z")
The `-cxx-interoperability-mode` command line option for the `swiftc` compiler used to work, but then (seemingly after an update to MS Visual Studio 2022) it stopped. How to reproduce: Create a `dynamicLibrary.swift` file: ```swift public func foo() -> Int { return 42 } ``` Try to compile it with the following command: `swiftc dynamicLibrary.swift -emit-library -cxx-interoperability-mode=default` Expected result: dynamic library is created. Actual result: The following console output: ```swift e[1m:1:10: e[0me[0;1;30mnote: e[0me[1min file included from :1: e[0m#include "ccomplex" e[0;1;32m ^ e[0me[1mC:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include/ccomplex:8:10: e[0me[0;1;30mnote: e[0me[1min file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include/ccomplex:8: e[0m#include e[0;1;32m ^ e[0me[1mC:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\yvals_core.h:898:1: e[0me[0;1;31merror: e[0me[1mstatic assertion failed: error STL1000: Unexpected compiler version, expected Clang 17.0.0 or newer. e[0m_EMIT_STL_ERROR(STL1000, "Unexpected compiler version, expected Clang 17.0.0 or newer."); e[0;1;32m^ e[0me[1mC:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\yvals_core.h:519:44: e[0me[0;1;30mnote: e[0me[1mexpanded from macro '_EMIT_STL_ERROR' e[0m#define _EMIT_STL_ERROR(NUMBER, MESSAGE) static_assert(false, "error " #NUMBER ": " MESSAGE) e[0;1;32m ^ e[0me[1m:0: e[0me[0;1;31merror: e[0me[1mcould not build C module 'std' e[0merror: fatalError ``` ---
**Author:** ![etcwilde](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/etcwilde/32/13687_2.png) [@etcwilde](https://forums.swift.org/u/etcwilde)\ **Post date:** [June 14, 2024, 4:43am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/2 "2024-06-14T04:43:18Z")
Yes, Microsoft updated the minimum required version of Clang to Clang 17. The clang that is embedded in the Swift compiler for importing C and C++ APIs is aligned with the Clang 16 release. For the time being, you will need to use an older Windows SDK that is compatible with Clang 16 (or older). Edit: At least according to the [WinGet installation documentation](https://www.swift.org/install/windows/winget/), `Microsoft.VisualStudio.Component.Windows11SDK.22000` should work. ---
**Author:** ![dima\_kozhinov](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dima\_kozhinov](https://forums.swift.org/u/dima_kozhinov)\ **Post date:** [June 15, 2024, 9:57am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/3 "2024-06-15T09:57:29Z")
> [@etcwilde](#): > > `Microsoft.VisualStudio.Component.Windows11SDK.22000` should work Nope. Just did a clean install of `Microsoft.VisualStudio.Component.Windows11SDK.22000` (no later SDKs installed). Same error message. ---
**Author:** ![tiff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tiff/32/24177_2.png) [@tiff](https://forums.swift.org/u/tiff)\ **Post date:** [June 15, 2024, 11:48am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/4 "2024-06-15T11:48:29Z")
I believe this can be avoided by adding the following compiler flags to the command ```swift -Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH ``` Alternatively, you can add them to the cxxSettings of Package.swift, like this ```swift cxxSettings: [ .define("_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH", .when(platforms: [.windows])) ] ``` ---
**Author:** ![dima\_kozhinov](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dima\_kozhinov](https://forums.swift.org/u/dima_kozhinov)\ **Post date:** [June 15, 2024, 3:32pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/5 "2024-06-15T15:32:38Z")
> [@tiff](#): > > `-Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH` It works, thank you. What are the implications of ignoring the version mismatch? Is generated binary technically correct? ---
**Author:** ![stevapple](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stevapple/32/31979_2.png) [@stevapple](https://forums.swift.org/u/stevapple)\ **Post date:** [June 16, 2024, 2:13am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/6 "2024-06-16T02:13:05Z")
Visual C++ STL is packaged along with MSVC tools, and has nothing to do with the Windows SDK. This is a breaking change introduced _within_ VS 17.x release cycle, and the valid workaround should be to manually install an older MSVC toolchain and specify it manually with `-visualc-tools-root`. ---
**Author:** ![tiff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tiff/32/24177_2.png) [@tiff](https://forums.swift.org/u/tiff)\ **Post date:** [June 16, 2024, 2:14am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/7 "2024-06-16T02:14:19Z")
It means that the Microsoft STL is the version that has been tested with Clang. ([this article](https://devblogs.microsoft.com/cppblog/c17-progress-in-vs-2017-15-5-and-15-6/)). It is expected to typically work unless you are using the latest features (perhaps C++23 or 26?). If you encounter problems, try installing a different version of the STL ([download](https://github.com/microsoft/STL/releases)), or you can find information about it [here.](https://github.com/microsoft/STL/wiki/Changelog) ---
**Author:** ![stevapple](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stevapple/32/31979_2.png) [@stevapple](https://forums.swift.org/u/stevapple)\ **Post date:** [June 16, 2024, 2:17am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/8 "2024-06-16T02:17:50Z")
I think we need a table to clarify the version of Clang packed within the Swift toolchain, and match it with STL requirements (if such version bump is still going to happen). ---
**Author:** ![dima\_kozhinov](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dima\_kozhinov](https://forums.swift.org/u/dima_kozhinov)\ **Post date:** [June 16, 2024, 4:30am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/9 "2024-06-16T04:30:32Z")
> [@tiff](#): > > It is expected to typically work unless you are using the latest features (perhaps C++23 or 26?) I use C++ interoperability to just emit a C/C++ header file with the `-emit-clang-header-path` option of the `swiftc` compiler. No C++ code actually involved, just Swift. ---
**Author:** ![dima\_kozhinov](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dima\_kozhinov](https://forums.swift.org/u/dima_kozhinov)\ **Post date:** [June 16, 2024, 4:34am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/10 "2024-06-16T04:34:17Z")
> [@stevapple](#): > > Visual C++ STL is packaged along with MSVC tools, and has nothing to do with the Windows SDK Shouldn't Swift compiler rely on Windows SDK only, and not a closed-source commercial product from Microsoft? Next time Microsoft may break the entire compiler, not just one feature. ---
**Author:** ![stevapple](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stevapple/32/31979_2.png) [@stevapple](https://forums.swift.org/u/stevapple)\ **Post date:** [June 16, 2024, 4:42am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/11 "2024-06-16T04:42:32Z")
It’s not Swift depending on VC++, it is Clang that really depends on it (by default, on Windows). In theory you can use another C ABI with Swift, but in that way you’re no longer able to build directly against MSVC ABI, eg. with a hypothetical Swift SDK for Cygwin or msys2. ---
**Author:** ![furby-tm](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/furby-tm/32/34349_2.png) [@furby-tm](https://forums.swift.org/u/furby-tm)\ **Post date:** [August 2, 2024, 7:38pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/12 "2024-08-02T19:38:34Z")
Will **Swift 6** on **Windows** embed a clang aligned with the **Clang 17** release? There's alot of friction here for Windows users, since none of this is documented and most users will simply follow these [docs](https://www.swift.org/install/windows/winget/), which at the time of writing - correlates to every C/C++ target failing to compile for users, which is not quite the out-of-the-box experience Swift provides on all other platforms. * * * As an additional note, **Release** (`swift build -c release`) builds, as well as **Optimized** (`swift build -Xcc -Os`) builds of C/C++ targets also break C++ interop on **Windows**. Example output (slightly redacted to avoid printing too much noise in this comment) when compiling C/C++ targets with one of the aforementioned commands: ```swift Function has token parameter but isn't an intrinsic call void @_GLOBAL__sub_I_tag.cpp.cold.1(token %0) #22, !dbg !4333 in function _GLOBAL__sub_I_tag.cpp fatal error: error in backend: Broken function found, compilation aborted! PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. ... 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'C:\Users\furby\Wabi\MetaverseKit\Sources\Yaml\tag.cpp'. 4. Running pass 'Module Verifier' on function '@_GLOBAL__sub_I_tag.cpp' Exception Code: 0xE0000046 #0 0x00007ffd7f2fc95a (C:\WINDOWS\System32\KERNELBASE.dll+0xcc95a) #1 0x00007ff78960316a (C:\Users\furby\AppData\Local\Programs\Swift\Toolchains\5.10.1+Asserts\usr\bin\clang.exe+0x16e316a) ... clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 16.0.0 Target: x86_64-unknown-windows-msvc Thread model: posix InstalledDir: C:\Users\furby\AppData\Local\Programs\Swift\Toolchains\5.10.1+Asserts\usr\bin ... ``` * * * As a final observation, with the following define present ```swift cxxSettings: [ .define("_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH", .when(platforms: [.windows])) ] ``` with a single C++ target's header file including the following ```cpp // SomeCXXTarget.h #include // from stdlib ``` it errors with the following when attempting to import it into Swift: ```swift // SomeApp.swift import SomeCXXTarget ^ ~~~~~~~~~~~~ vcruntime.modulemap:696:10: error: module 'std.version' requires feature 'cplusplus20' ``` **Note** : I am using the following C/C++ language standards in my **`Package.swift`** manifest. ```swift cLanguageStandard: .gnu17, cxxLanguageStandard: .cxx17 ``` * * * Thanks! ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [August 2, 2024, 8:31pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/13 "2024-08-02T20:31:13Z")
The IR Verification error regarding "Function has token parameter but isn't an intrinsic" is related to Hot/Cold Splitting (HCS). This was recently fixed upstream and I've backported it for the 6.0 release. You can disable cold code splitting to avoid this error. The error with `std.version` is related to the C++ standard you are using (C++17). Bumping that to C++20 should alleviate that. The Microsoft STL aggressively adopts new C++ features requiring that you update the versions pretty quickly. ---
**Author:** ![furby-tm](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/furby-tm/32/34349_2.png) [@furby-tm](https://forums.swift.org/u/furby-tm)\ **Post date:** [August 2, 2024, 8:42pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/14 "2024-08-02T20:42:18Z")
> The error with `std.version` is related to the C++ standard you are using (C++17). Bumping that to C++20 should alleviate that. The Microsoft STL aggressively adopts new C++ features requiring that you update the versions pretty quickly. I'm afraid that bumping the C++ standard to C++20 is an astronomically breaking change. I use Swift/C++ interop to build much of the [**ASWF projects**](https://landscape.aswf.io/) and all if its dependencies, changing the C++ standard has drastic breaking changes across nearly every library. The best way forward here was ensuring that `` does not exist in any of the Swift imports on the Windows platform, for me it was coming from the [**oneTBB**](https://github.com/oneapi-src/oneTBB) dependency, simply ensuring the header including that file was nowhere visible in the umbrella header was enough to workaround the issue, allowing me to keep the standard strictly to C++17. _Which leads me to the question, **why error here?** _ Is it possible to have Swift ignore incompatible modulemaps and simply not import their APIs into Swift if this is the case? This issue is a Swift one, not a C++ one (the error only occurs during the compilation of the **Swift** file that imports an offending target that imports incompatible modulemaps). * * * > The IR Verification error regarding "Function has token parameter but isn't an intrinsic" is related to Hot/Cold Splitting (HCS). This was recently fixed upstream and I've backported it for the 6.0 release. You can disable cold code splitting to avoid this error. Great work! Is that available from this download [**here**](https://download.swift.org/development/windows10/swift-DEVELOPMENT-SNAPSHOT-2024-07-02-a/swift-DEVELOPMENT-SNAPSHOT-2024-07-02-a-windows10.exe)? ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [August 2, 2024, 10:24pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/15 "2024-08-02T22:24:29Z")
> [@furby-tm](#): > > Is it possible to have Swift ignore incompatible modulemaps and simply not import their APIs into Swift if this is the case? This issue is a Swift one, not a C++ one (the error only occurs during the compilation of the **Swift** file that imports an offending target that imports incompatible modulemaps). Not AFAIK; the modulemaps will be loaded. In the case of the umbrella header, all of those were re-exported and thus caused the module to be serialised and loaded. > [@furby-tm](#): > > Great work! Is that available from this download [**here**](https://download.swift.org/development/windows10/swift-DEVELOPMENT-SNAPSHOT-2024-07-02-a/swift-DEVELOPMENT-SNAPSHOT-2024-07-02-a-windows10.exe)? No, it requires a newer snapshot that will hopefully be made available there soon (CC: @mishal_shah). ---
**Author:** ![processeus](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/processeus/32/36814_2.png) [@processeus](https://forums.swift.org/u/processeus)\ **Post date:** [August 8, 2024, 8:05am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/16 "2024-08-08T08:05:33Z")
Has anybody managed to download the older version of Visual Studio / standard library? Assuming I need MSVC 17, I would need to install Visual Studio 2019 Community, which I couldn't find anywhere (it's not available on winget and on the official older versions download page) ---
**Author:** ![furby-tm](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/furby-tm/32/34349_2.png) [@furby-tm](https://forums.swift.org/u/furby-tm)\ **Post date:** [August 28, 2024, 8:38pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/17 "2024-08-28T20:38:30Z")
I started experiencing a super weird issue with the MSVC C++ Standard Library in github actions, something changed with `windows-latest` and now you cannot `#include ` with this [error on **v14.41.34120**](https://github.com/wabiverse/MetaverseKit/actions/runs/10603341003/job/29387436729#step:5:705), I do not however experience this issue on **v14.40.33807**. The error is the following: ```swift C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.41.34120\include\tuple:957:9: error: static assertion failed: get(tuple&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5) ``` Did Microsoft break their own C++ Standard Library and ship that error? 😅 @compnerd I'm not sure if you know what might be going on here, but it's quite strange, thanks! ---
**Author:** ![dima\_kozhinov](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dima\_kozhinov](https://forums.swift.org/u/dima_kozhinov)\ **Post date:** [August 28, 2024, 11:00pm UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/18 "2024-08-28T23:00:17Z")
After one more Microsoft update things are broken again ☹ The ```swift -Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH ``` does not help anymore, apparently the problem is different this time. Again, how to reproduce: - Create a minimal dynamicLibrary.swift file, e.g. ```swift public func foo() -> Int { return 42 } ``` - Try to compile it with the following command: `swiftc dynamicLibrary.swift -emit-library -cxx-interoperability-mode=default -Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH` > **Compiler output** > > ```swift > :1:10: note: in file included from :1: > #include "ccomplex" > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/ccomplex:11:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/ccomplex:11: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\complex:13:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\complex:13: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\sstream:10:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\sstream:10: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\istream:10:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\istream:10: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\ostream:10:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\ostream:10: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\ios:10:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\ios:10: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\xlocnum:15:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\xlocnum:15: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\iterator:11:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\iterator:11: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\xutility:11:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\xutility:11: > #include <__msvc_iter_core.hpp> > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\__msvc_iter_core.hpp:10:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\__msvc_iter_core.hpp:10: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\utility:11:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\utility:11: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\type_traits:131:5: error: static assertion failed: Calling declval is ill-formed, see N4950 [declval]/2. > static_assert(false, "Calling declval is ill-formed, see N4950 [declval]/2."); > ^ > :33:10: note: in file included from :33: > #include "condition_variable" > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\tuple:957:9: error: static assertion failed: get(tuple&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5) > static_assert(false, "get(tuple&) " > ^ > :33:10: note: in file included from :33: > #include "condition_variable" > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\tuple:969:9: error: static assertion failed: get(const tuple&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5) > static_assert(false, "get(const tuple&) " > ^ > :33:10: note: in file included from :33: > #include "condition_variable" > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\tuple:981:9: error: static assertion failed: get(tuple&&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5) > static_assert(false, "get(tuple&&) " > ^ > :33:10: note: in file included from :33: > #include "condition_variable" > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include/condition_variable:17: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\mutex:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18:10: note: in file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\thread:18: > #include > ^ > C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.41.34120\include\tuple:993:9: error: static assertion failed: get(const tuple&&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5) > static_assert(false, "get(const tuple&&) " > ^ > :0: error: could not build C module 'std' > error: fatalError > > ``` ---
**Author:** ![furby-tm](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/furby-tm/32/34349_2.png) [@furby-tm](https://forums.swift.org/u/furby-tm)\ **Post date:** [August 29, 2024, 7:01am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/19 "2024-08-29T07:01:19Z")
Yep same error as mine above, MSVC 14.41 is the culprit As far as I know this is a unfixable bug in this specific version of MSVC, I don’t think there’s anything Swift is doing causing this error, but also it would seem very odd if this specific version of MSVC is totally broken, so I’m not quite sure how to explain this ![IMG_0290](https://global.discourse-cdn.com/swift/original/3X/d/c/dc6dfac4b7a61cf22210425802e489728b8c0e13.gif) ---
**Author:** ![furby-tm](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/furby-tm/32/34349_2.png) [@furby-tm](https://forums.swift.org/u/furby-tm)\ **Post date:** [August 29, 2024, 7:29am UTC](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462/20 "2024-08-29T07:29:52Z")
Out of curiosity, if you set the C++ Language Standard to 20 does that “fix” this error? (I know it’s not a real fix, I’m just curious if that gets things rolling again as a pretty dramatic workaround, this version mismatch is less than ideal). [Next page](https://forums.swift.org/t/c-interoperability-is-broken-windows-platform/72462.md?page=2)