https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124268
--- Comment #7 from Nathaniel Shead <nshead at gcc dot gnu.org> --- In the general case, the '.o' generated by building the module TU must be linked into the final executable. This is important for ABI reasons, because any non-vague-linkage entities in that TU will be emitted into that .o. If the same module being built with different flags provides different symbols and they are all linked into the same program then you're going to run into issues anyway I guess? The 'std' module I guess is a little special, because on most targets it has no non-vague-linkage entities (everything comes from #includes). But on Windows (unlike typical Linux systems) it does actually have something important: the initialisers for 'std::cout' and friends. These are what's called in the initialiser function for the module. There's no strict reason going into the future that they are the only such symbols too, I guess it could happen that a future C++ version adds new globals with dynamic initialisation. Or maybe there's a flag to configure how initialisation of such globals are done for targets like Windows. (Or maybe in the future an ABI-breaking version of the standard library is made with all entities defined inside the module and headers just do 'import std.compat' and provide macros? Though that's probably unlikely!) But in general I think it's not safe to treat the standard library specially and assume we don't have to link the generated object file from compiling the library. And if we do have to provide this build .o I wonder if there are sets of flags we'd need to build it differently for to handle different outputs.
