Add built-in dynamic build with static CRT

[NN---]

Describe the pull request

• What does your PR fix?

  Fixes Support for dynamic runtime with static linking? #1131

• Which triplets are supported/not supported? Have you updated the CI baseline?

Adding new triplet for Windows.
It is possible to add it manually, however I see many developers are struggling with the same issue.
Building dynamic library (DLL) while not using dynamic dependency on VC Runtime.

[Neumann-A]

I think the answer to this was a big NO, since it can introduce serious bug if objects get passed over DLL boundaries and allocated and then deallocated by different CRTs.

[NN---]

This is known issue. If you pass C++ objects over dynamic library boundary without using the same CRT it is not safe.
This why dynamic libraries expose C API and not C++ API.
Check the issues, many people need this triplet.

[Neumann-A]

This why dynamic libraries expose C API and not C++ API.

This is not generally true.

Check the issues, many people need this triplet.

--overlay-triplets=<path_to_your_dangerous_triplets> ?

[NN---]

Whoever needs this triplet, knows why it is needed.
I just ask to have it bundled with vcpkg.

[JackBoosY]

Since they are not the official triplets, please move these triplet file to triplets/community .

[NN---]

@JackBoos Done.

[JackBoosY]

How about rename the triplets to x64-windows-mt and x86-windows-mt?

[NN---]

Do you have a better name ?

[JackBoosY]

@NN--- I think x64-windows-mt and x86-windows-mt would be okay.

[BillyONeal]

I don't believe we can ever merge this.

Most libraries in vcpkg are not prepared to deal with this type of configuration. They speak standard library types in their interfaces, or throw exceptions, neither of which are safe to do when the standard library types are "owned" by different C runtime instances. When you statically link with the C runtime in a DLL, each DLL gets its own entire copy of the C runtime, and all state that may depend on global variables therein is unsafe to use.

For example, the iterator debug machinery is protected by the debug lock, which is a global variable that lives in msvcp140.dll/libcpmt.lib. If you have a DLL that exposes a function that has a const std::vector&, that library cannot be used in such a configuration, because each DLL thinks it is taking a lock protecting the debugging data structures, when in reality they are taking different locks.

(This problem is similar to static libraries using a dynamic CRT as previously discussed in #16387 and #15122 , but the probability of triggering the problem goes from "possible" to "certain" in this case, as even use of the core language triggers breakage.)

[BillyONeal]

I also observe that this change seems unrelated to #36 (which requests completely static linking served by today's foo-windows-static triplets) and #15386 (which again is served by complete static linking)

[NN---]

This is correct that using C++ API between libraries in such scenario is problematic.
However there is no problem when you use a library with C API.
For instance libssh exposes C API, therefore you can use it safely.

[ras0219-msft]

@BillyONeal's comment #19005 (review) explains why this can never be an official or community vcpkg triplet.

However, if you are an advanced user with one of the few valid use cases, this is always a possible triplet to define on your own and use via overlay-triplets.

Thanks for the PR!