Windows Universal CRT and the approach to "hybrid" runtime linking

[trueqbit]

I am proposing a new build variant on Windows that allows a "hybrid" runtime approach.

I am uncertain where to start this discussion, because it affects both, boost-config and bfgroup-b2/boost-build.

Motivation

Since Windows 7, Windows has delivered the ABI-stable subset of the C runtime as part of the operating system in the form of the "Universal CRT".
This allows libraries to be created without the ballast of a statically linked in runtime and without the need to deploy the "VC runtime", i.e. a kind of lightweight yet self-contained hybrid.

This approach is officially used by the "Windows App SDK", and I am using it successfully for all FireDaemon Technologies LTD products.
Also openssl accepted the new build configuration.
More information about Hybrid CRT can be found here: https://github.com/microsoft/WindowsAppSDK/blob/main/docs/Coding-Guidelines/HybridCRT.md.

This is very easy to achieve:

1. instruct the msvc compiler to link to the static runtime library using the compiler flag /MT.
2. instruct the linker to link against the shared Universal CRT by using the linker flags /NODEFAULTLIB:libucrt.lib /DEFAULTLIB:ucrt.lib.

From a build perspective, this state can actually already be achieved by specifying variant=debug link=shared runtime-link=static linkflags="/NODEFAULTLIB:libucrtd.lib /DEFAULTLIB:ucrtd.lib" to b2; when building shared DLLs the additional argument --allow-shared-static needs to be passed.

Linking to such hybrid libraries is a bit more tricky.
Linking to "static" libraries would already work, but importing hybrid "dynamic" libraries is rejected by config/auto_link.hpp because it determines that "Mixing a dll boost library with a static runtime is a really bad idea...". With the dependency on the Universal CRT this is no longer true.

Proposal

Anyway, changing the traditional meaning of "static runtime" linking shouldn't be changed, and unfortunately there's no built-in CPP macro that is set by the msvc toolchain for that specific combination of runtime link flags.

Rather I propose:

1. a new boost configuration macro, e.g. BOOST_WINDOWS_LINK_UNIVERSAL_CRT that must be defined by importing projects.
2. a new runtime-tag letter 'h' denoting the "hybrid" nature of runtime linking.
3. a new b2 option runtime-link=hybrid
   a. writes runtime-tag 'h' into the resulting library file name.
   b. implicitly adds linkflags="/NODEFAULTLIB:libucrt.lib /DEFAULTLIB:ucrt.lib".

[grafikrobot]

From a build perspective using the UCRT is orthogonal to either the link or runtime-link. As you could be creating a static library that uses the UCRT (for eventual linking to an EXE or DLL). Hence neither of those features fit what you want. But we already do have a feature which is for this type of choice.. stdlib (https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.builtin.features.stdlib). Hence my suggestion would be to add a value to stdlib to cover the UCRT and have the build adjust the flags as needed to deal wit the combinations of link + runtime-link + stdlib. With the understanding that some permutations would be invalid for the UCRT.

[trueqbit]

Hi @grafikrobot How exactly is linking to the UCRT orthogonal? Not at all: It's definitely a variant of runtime-link, but has absolutely nothing to do with link. It doesn't matter whether the binary form of the resulting library is a static or shared module. I might well be that for a static library, the runtime-linkage doesn't matter, since the consuming executable decides this. Nevertheless, I create all static and shared boost libraries with runtime-link=hybrid to ensure that the implicit and explicit dependencies are clearly specified. This makes everything easy, and since the runtime tag goes into the library name, you immediately know how the libraries were built, and the linking machinery of e.g. boost's autolink.hpp can also be easily instructed to take the "hybrid" libraries.

[Kojoley]

@grafikrobot IIUC @trueqbit wants c-runtime-link=shared cxx-runtime-link=static like gcc -static-libstdc++ would do (on Linux it will link libc.so which is C runtime like UCRT on Windows).

IIRC Python extensions (.pyd) are built this way (by distutils/setuptools) because Python only has C API and needs shared C runtime to pass handlers across dll boundaries while it has no C++ API and doesn't want to deal with dll hell or shipping all the different vcruntimes (previously they specified which VS version have to be used for every Python version).

[trueqbit]

@Kojoley You have understood this correctly and described it in other, much shorter words!
@grafikrobot Is there any chance that this will be included in b2? It would also simplify library build scripts. The requirement is sort of simple, but the details are not, as things are platform/compiler dependent.

[grafikrobot]

I understand. And, yes, we can do something to accomplish that. But, yes, there are a lot of details on this one. Essentially every toolset would need changes.