The Qt fixtures state cxx_runtime in [build]: mcpp reads a [target.<triple>] table only when a target is named, so a host build embedded a second libstdc++ and QtCore's RUNPATH found none

Author: Sunrisepeak

README.md

@@ -993,8 +993,10 @@ the build is where the absence fails.
 On Linux, Qt's official QtCore links glib, zstd and zlib and the shared
 `libstdc++`. `rules-qt-xim` declares the first three on Linux, and the rule
 declares their `lib/` directories as runtime search directories; the program
-states `cxx_runtime = "toolchain-coupled"` for its Linux triple (mcpp's
-docs/20), so the process has one C++ runtime. Modules that load QtGui are not
+states `[build] cxx_runtime = "toolchain-coupled"` (mcpp's docs/20), so the
+process has one C++ runtime. The statement is project-wide because mcpp reads a
+`[target.<triple>]` table only when a target is named; under MSVC it keeps
+`/MD`, and on macOS mcpp keeps the default and says so. Modules that load QtGui are not
 served on Linux: QtGui loads `libdbus-1.so.3`, which the ecosystem does not
 publish, and mcpp's runtime closure check refuses the program. On macOS the
 modules are frameworks under `lib/`: the rule compiles with `-F<root>/lib` and

tests/qt-consumer/mcpp.toml

@@ -31,14 +31,14 @@ import_std = false
 plugins = { path = "../..", features = ["rules-qt-xim"], host-module = true }
 
 [build]
-sources = ["src/*.cpp", "res/*.qrc", "i18n/*.ts"]
-
-# Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so a
-# program that links them uses the toolchain's shared C++ runtime rather than
-# embedding one: two C++ runtimes in one process is the hazard mcpp's docs/20
-# describes, and mcpp reports it when the default applies.
-[target.x86_64-linux-gnu]
+# Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so the
+# program uses the toolchain's shared C++ runtime rather than embedding a second
+# one (mcpp's docs/20). The statement is project-wide because mcpp reads a
+# `[target.<triple>]` table only when a target is named. On Windows it keeps
+# `/MD`, which Qt's MSVC build uses, and stages the toolset's runtime DLLs; on
+# macOS mcpp reports that it keeps the default.
 cxx_runtime = "toolchain-coupled"
+sources = ["src/*.cpp", "res/*.qrc", "i18n/*.ts"]
 
 [targets.qt-consumer]
 kind = "bin"

tests/qt-widgets-consumer/mcpp.toml

@@ -22,19 +22,17 @@ import_std = false
 [build-dependencies.mcpp]
 plugins = { path = "../..", features = ["rules-qt-xim"], host-module = true }
 
-[build]
-sources = ["src/*.cpp", "ui/*.ui"]
-
 # Built and run on Windows and macOS by CI; on Linux QtGui needs libdbus, which
-# the ecosystem does not publish. The Linux runtime contract below is what a
-# Linux build of it states.
-#
-# Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so a
-# program that links them uses the toolchain's shared C++ runtime rather than
-# embedding one: two C++ runtimes in one process is the hazard mcpp's docs/20
-# describes, and mcpp reports it when the default applies.
-[target.x86_64-linux-gnu]
+# the ecosystem does not publish.
+[build]
+# Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so the
+# program uses the toolchain's shared C++ runtime rather than embedding a second
+# one (mcpp's docs/20). The statement is project-wide because mcpp reads a
+# `[target.<triple>]` table only when a target is named. On Windows it keeps
+# `/MD`, which Qt's MSVC build uses, and stages the toolset's runtime DLLs; on
+# macOS mcpp reports that it keeps the default.
 cxx_runtime = "toolchain-coupled"
+sources = ["src/*.cpp", "ui/*.ui"]
 
 [targets.qt-widgets-consumer]
 kind = "bin"