Observation
A host build does not read the [target.<triple>] section whose triple is the host's. The section's cxx_runtime has no effect, and the build does not report that it ignored the section.
Measured on 2026.9.26.1 and 2026.9.26.2, Linux x86_64, gcc@16.1.0:
[package]
name = "cxxrt"
version = "0.1.0"
[language]
standard = "c++23"
import_std = false
[target.x86_64-linux-gnu]
cxx_runtime = "toolchain-coupled"
[targets.cxxrt]
kind = "bin"
main = "src/main.cpp"
| command |
NEEDED libstdc++.so.6 |
mcpp build |
absent (self-contained) |
mcpp build --target x86_64-linux-gnu |
present |
mcpp build with [build] cxx_runtime = "toolchain-coupled" |
present |
src/build/prepare.cppm consults targetOverrides only when overrides.target_triple is set (--target, [build] target, or a configured default target). The warning for [target.'cfg(linux)'.build] cxx_runtime directs the user to [target.<triple>].cxx_runtime, which a host build then ignores.
Consequence
A program that links Qt's official Linux libraries embeds libstdc++, and each Qt library requires libstdc++.so.6. QtCore carries RUNPATH $ORIGIN, so the loader does not search the executable's RPATH for QtCore's dependencies, and the program fails at start with libstdc++.so.6: cannot open shared object file. The engine's interposition check reports the embedded copy: 72 symbols are also provided by the toolchain's libstdc++.so.6. mcpp-plugins 0.13.0 (rules-qt) states the contract in [build] for this reason.
Proposed behaviour
- A host build resolves the host triple and applies the matching
[target.<triple>] section, using the same spelling-independent comparison as --target. The remaining keys of that section already describe the host target in every other respect.
- Alternatively, the build reports a
[target.<triple>] section whose triple is the host's and which the build did not read.
A further generalisation would extend the 2026.9.16.1 rule, under which an ELF program whose contract nobody stated adopts the contract of a C++ shared library that the build makes. The same rule would apply to a prebuilt shared library in the link that has NEEDED libstdc++.so.6. Qt users would then state nothing.
Observation
A host build does not read the
[target.<triple>]section whose triple is the host's. The section'scxx_runtimehas no effect, and the build does not report that it ignored the section.Measured on 2026.9.26.1 and 2026.9.26.2, Linux x86_64, gcc@16.1.0:
NEEDED libstdc++.so.6mcpp buildmcpp build --target x86_64-linux-gnumcpp buildwith[build] cxx_runtime = "toolchain-coupled"src/build/prepare.cppmconsultstargetOverridesonly whenoverrides.target_tripleis set (--target,[build] target, or a configured default target). The warning for[target.'cfg(linux)'.build] cxx_runtimedirects the user to[target.<triple>].cxx_runtime, which a host build then ignores.Consequence
A program that links Qt's official Linux libraries embeds libstdc++, and each Qt library requires
libstdc++.so.6. QtCore carriesRUNPATH $ORIGIN, so the loader does not search the executable's RPATH for QtCore's dependencies, and the program fails at start withlibstdc++.so.6: cannot open shared object file. The engine's interposition check reports the embedded copy: 72 symbols are also provided by the toolchain'slibstdc++.so.6. mcpp-plugins 0.13.0 (rules-qt) states the contract in[build]for this reason.Proposed behaviour
[target.<triple>]section, using the same spelling-independent comparison as--target. The remaining keys of that section already describe the host target in every other respect.[target.<triple>]section whose triple is the host's and which the build did not read.A further generalisation would extend the 2026.9.16.1 rule, under which an ELF program whose contract nobody stated adopts the contract of a C++ shared library that the build makes. The same rule would apply to a prebuilt shared library in the link that has
NEEDED libstdc++.so.6. Qt users would then state nothing.