# Unexpected VS2022 build flag changes with CMake 4.1
**URL:** https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324
**Category:** Usage
**Tags:** os:windows, comp:msvc, gen:vs
**Created:** [November 18, 2025, 11:38pm UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324 "2025-11-18T23:38:13Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@kwaegel](https://discourse.cmake.org/u/kwaegel)
#### Post date: [November 18, 2025, 11:38pm UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/1 "2025-11-18T23:38:14Z")
I recently tried upgrading CMake and got an unexpected build failure with Visual Studio 2022 suddenly returning LNK1189 (\>65k symbols) for a large private project. After a bunch of testing different versions, it looks like the upgrade from CMake 4.0 to 4.1 changes the build flags in a way that results in a ton more symbols being exported when `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS` is enabled.
The large failing project is private, but I created a minimal test project to debug what flags changed. I attached some text files with the flag lists for a minimal .dll test project, and it looks like `/Zc:wchar_t`, `/Zc:inline`, and `/Zc:forScope` were removed. From looking at the MSVC docs, [/Zc:inline (Remove unreferenced COMDAT)](https://learn.microsoft.com/en-us/cpp/build/reference/zc-inline-remove-unreferenced-comdat?view=msvc-170) seems like the most likely cause of LNK1189, since it was likely removing unused symbols that are now getting exported.
Was this change intended? I tried reading over the [CMake 4.1 release notes](https://cmake.org/cmake/help/latest/release/4.1.html), but haven’t seen anything that describes the changes I’m seeing.
[simple\_flags\_4.0.4.txt](https://discourse.cmake.org/uploads/short-url/aJlEZYEkhjO9D79MwtcNMb43i7r.txt) (1.2 KB)
[simple\_flags\_4.1.2.txt](https://discourse.cmake.org/uploads/short-url/bgZeH7wXsay29X4InCKL0YYV4dA.txt) (1.1 KB)
[CMakeLists.txt](https://discourse.cmake.org/uploads/short-url/u20XjwoAnPRTIGRWpnx0ShtxhjW.txt) (1.0 KB)
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [November 19, 2025, 8:38pm UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/2 "2025-11-19T20:38:10Z")
The only change mentioning `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS` that I can see for CMake 4.1 is [MR 10791](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10791), but that MR looks like it should _reduce_ the number of exported symbols and it doesn’t seem to be doing anything with the compiler flags you mentioned.
@brad.king Are you aware of any other changes related to `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS` that went into CMake 4.1? This post sounds like there has been a regression.
---
### Author:  [@kwaegel](https://discourse.cmake.org/u/kwaegel)
#### Post date: [November 20, 2025, 12:58am UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/3 "2025-11-20T00:58:34Z")
I tried explicitly adding `/Zc:inline` to our internal project again, and it fixed the LNK1189 error. The number of exported symbols in the .def file dropped by 7x (200,000 down to ~27,000, lots of Eigen templates). Seems very likely that changing that flag was the cause.
Speculating a bit, it looks like the other two flags that changed (`/Zc:wchar_t` and `/Zc:forScope`) are on by default according to [the MSVC docs](https://learn.microsoft.com/en-us/cpp/build/reference/zc-conformance?view=msvc-170), so I’m wondering if something changed to stop setting unnecessary flags and accidentally also affected `/Zc:inline`?
---
### Author:  [@kwaegel](https://discourse.cmake.org/u/kwaegel)
#### Post date: [November 20, 2025, 1:06am UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/4 "2025-11-20T01:06:40Z")
I poked around in the 4.1 changes list, and this looks relevant:
> `Microsoft.Cl.Common.props` adds some `cl` flags by default, but for CMake they may not match what’s produced by command-line generators. If the `-Zc:wchar_t`, `-Zc:forScope`, and/or `-Zc:inline` flags are not specified by the project or user, suppress them.
[https://gitlab.kitware.com/cmake/cmake/-/issues/26964](https://gitlab.kitware.com/cmake/cmake/-/issues/26964)
[https://gitlab.kitware.com/cmake/cmake/-/merge\_requests/10851](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10851)
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 20, 2025, 2:35pm UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/5 "2025-11-20T14:35:53Z")
Yes, removal of those flags was intentional. We are willing to make such changes without a policy when it is about consistency among generators. In this case MSBuild was adding flags the project didn’t specify. If a project needs particular flags, it should specify them, and then it will work in all generators, not just Visual Studio.
---
### Author:  [@kwaegel](https://discourse.cmake.org/u/kwaegel)
#### Post date: [November 20, 2025, 7:26pm UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/6 "2025-11-20T19:26:49Z")
Thanks. That was sort of my impression from reading the PR, but good to get it confirmed.
Might have been useful to have a note in the CMake 4.1 change log, but I’m not actually sure how much time it would have saved me. I was already a couple of days into re-installing different MSVC toolsets and Windows SDK versions before I thought to check CMake. A bunch of stuff got updated around the same time, which kind of muddied the waters for a while.
In the end, the fix for my project was to enable pretty much every `/Zc:` conformance flag that wasn’t listed as “on by default” in the MSVC docs, including the `/Zc:inline` one in question here.
Thanks for taking the time to look into this. 🙂
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [December 8, 2025, 4:02pm UTC](https://discourse.cmake.org/t/unexpected-vs2022-build-flag-changes-with-cmake-4-1/15324/7 "2025-12-08T16:02:55Z")
[CMake MR 11489](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11489) updates the 4.1 release notes for this.