Jens-G opened a new pull request, #3894: URL: https://github.com/apache/thrift/pull/3894
`WITH_MT` is the option that makes the Windows compiler self-contained — linked against the static runtime so it runs on a machine with no Visual C++ redistributable installed. `build/docker/msvc/build-compiler.bat` passes it, the manual instructions in `doc/ReleaseManagement.md` pass it, and that document then asks the release manager to confirm with Dependency Walker that the result depends only on `kernel32.dll`. It has stopped doing anything. ## Evidence A `-DWITH_MT=ON` Release build of the compiler on a `windows-2025` runner (CMake 3.31.6, VS 2022) has this import table: ``` KERNEL32.dll ole32.dll MSVCP140.dll VCRUNTIME140.dll VCRUNTIME140_1.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-filesystem-l1-1-0.dll api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll ``` That is a `/MD` build. Full log: the `compiler-windows` job on [#3893](https://github.com/apache/thrift/pull/3893) (`Check the compiler is self-contained` step). The container that builds the release compiler installs CMake 4.1.2, so it is on the same side of the policy change. (`ole32.dll` is not part of the problem — it is a Windows system DLL, not a redistributable, pulled in by the `CoCreateGuid` call in `t_delphi_generator.cc`. The "only `kernel32.dll`" wording in `ReleaseManagement.md` simply predates that call.) ## Cause `build/cmake/DefinePlatformSpecifc.cmake` implemented `WITH_MT` by rewriting `/MD` to `/MT` in `CMAKE_CXX_FLAGS_RELEASE` and its siblings. [CMP0091](https://cmake.org/cmake/help/latest/policy/CMP0091.html) took the runtime library out of those variables and moved it to the `MSVC_RUNTIME_LIBRARY` target property, which `CMAKE_MSVC_RUNTIME_LIBRARY` initialises. The policy is NEW whenever a project requires CMake 3.15 or newer, and the top-level `CMakeLists.txt` requires 3.16, so there is no `/MD` left to replace. Neither `CMP0091` nor `CMAKE_MSVC_RUNTIME_LIBRARY` occurred anywhere in the tree. The failure is silent in every direction: the build succeeds, the configure summary still prints `Using static runtime library: ON`, and the static libraries are still named `thriftmt` — a name that promises a runtime the binaries do not have. ## Fix Set `CMAKE_MSVC_RUNTIME_LIBRARY` to `MultiThreaded$<$<CONFIG:Debug>:Debug>` when `WITH_MT` is on, before any target is created. The flag rewriting stays. It is what still selects the runtime for a build that sets `CMP0091` to `OLD`, and under `NEW` it is a no-op. Both paths are now covered, and the comment says which is which. ## Blast radius `WITH_MT` is only passed by the compiler build (`build-compiler.bat` and the documented VM recipe) — `grep` finds no other use, and AppVeyor does not set it. So no library artifact changes its name. What changes is that a `thriftmt` library now really is linked against the static runtime, which is what the name has always claimed. ## How it is verified This has no test of its own, because the test is a Windows CI job the project did not have. [#3893](https://github.com/apache/thrift/pull/3893) (THRIFT-6310) adds `compiler-windows` to `cmake.yml`, which builds with `-DWITH_MT=ON` and asserts the import table. That PR is currently red **because of this bug** — it is the failing test. It is stacked on this branch and goes green once this merges. Reviewing them in that order is the easiest way to see it: #3893's red run is the reproduction, this PR is the fix. JIRA: [THRIFT-6312](https://issues.apache.org/jira/browse/THRIFT-6312) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
