STL: /MD version does not load dynamic imports

[AlexGuteniev]

Describe the bug
/MD version of STL DLL built from sources does not call initialize_pointers() in winapisupp.cpp

Command-line test case

#include <mutex>

int main()
{
    std::mutex mx;
}

Build with /MD (not /MT or /MDd)

Step using disassembly deep into constructor, see that it creates Vista critical section, not win7

[CaseyCarter]

Confirmed: all of the __KERNEL32Functions are NULL, but only for /MD (that is, /MT, /MTd, and /MDd are fine). I know just enough to be dangerous here - I think vcstartup is responsible for running the initializers in section .CRT$XIC?

[AlexGuteniev]

I want to know more -- it is dangerous to implement constexpr mutex on top of this. Seems that the installed version of the STL DLL on my machine is fine. But could it affect another distributed version?

[StephanTLavavej]

The problem appears to be that winapisupp.cpp is being built with /GL for the GitHub/CMake /MD build.

winapisupp.cpp is treated like any other file in the CMake build:

STL/stl/CMakeLists.txt

Lines 313 to 315 in ee5a216

	${CMAKE_CURRENT_LIST_DIR}/src/winapinls.cpp
	${CMAKE_CURRENT_LIST_DIR}/src/winapisupp.cpp
	${CMAKE_CURRENT_LIST_DIR}/src/wiostrea.cpp

But winapisupp.cpp is special-cased in the legacy MSBuild:

STL/stl/msbuild/stl_base/stl.files.settings.targets

Lines 153 to 158 in ee5a216

	<BuildFiles Include="
	$(CrtRoot)\github\stl\src\winapisupp.cpp;
	">
	<BuildAs>nativecpp</BuildAs>
	<HasCrtInitializers>true</HasCrtInitializers>
	</BuildFiles>

Other than the STL (and ConcRT) using it, HasCrtInitializers is mentioned only by src/vctools/crt/crt_build.targets in the MSVC-internal repo:

<!-- In the retail build, we want everything that goes into a DLL to get /GLed, but at the moment that breaks CHPE and causes assertions. -->
<!-- TRANSITION, VSO#723435 for chpe -->
<!-- TRANSITION, VSO#723425 for BE parallelization assertions -->
<!--<BuildFiles Condition="
    ('%(BuildFiles.BuildAs)' == 'nativecpp' or '%(BuildFiles.BuildAs)' == 'nativec') and
    '$(TargetType)'                            == 'DYNLINK'   and
    '$(DebugBuild)'                            != 'true'      and
    '%(BuildFiles.IncludeInImportLib)'         != 'true'      and
    '%(BuildFiles.ForceIncludeInImportLib)'    != 'true'      and
    '%(BuildFiles.HasCrtInitializers)'         != 'true'      and
    '%(BuildFiles.ClWholeProgramOptimization)' == ''
">
    <ClWholeProgramOptimization>true</ClWholeProgramOptimization>
</BuildFiles> -->

From this, I conclude:

• Originally, legacy MSBuild was special-casing winapisupp.cpp to avoid compiling it with /GL
• Now, due to compiler backend bugs, legacy MSBuild isn't using /GL at all
• The modern CMake build isn't special-casing winapisupp.cpp, and is using /GL for the release DLL, which is why only /MD is affected

I believe we should special-case winapisupp.cpp and always avoid compiling it with /GL.

Additionally, we may want to consider disabling /GL for the modern CMake build, since we generally want it to produce the same results as legacy MSBuild - however, this may not be necessary/desirable (I am not sure how relevant the compiler backend bugs are here).