"Hybrid CRT" linking and DLLs

[patstew]

Microsoft has recently pushed the "hybrid CRT" linking method (https://aka.ms/hybridcrt) in its own App SDK recently. As I understand it, it basically means dynamically linking the UCRT while statically linking the STL and some other bits.
Is it safe/supported to use this linking method when you have dynamic libraries, using C++ APIs, so each DLL/EXE is statically linked with the STL/runtime but they're all dynamically linked to one UCRT?
Could this cause issues, e.g. with static data that's duplicated because it's in the STL/runtime and not the UCRT, or with RTTI, unwinding information etc not working across library boundaries?
I am under the impression that this works around the issues you'd normally get with /MT in that scenario, at least it works for me in practice. I'm currently trying to get Qt to accept a patch to optionally do hybrid CRT linking, and they think it should be for static builds only, it would help if someone from MS could say if it's supported for dynamic libraries or not.

Sorry if this is the wrong place to ask, I thought it might be more likely to get a reply from an expert who knows the answer here.

[StephanTLavavej]

Is it safe/supported to use this linking method when you have dynamic libraries, using C++ APIs, so each DLL/EXE is statically linked with the STL/runtime but they're all dynamically linked to one UCRT?

That's risking catastrophe. The moment you pass a single STL object across your DLL boundaries, you're risking severe doom (especially with anything touching our global data like locales, certain atomic locks). I wouldn't do this with anything other than a monolithic EXE.

I'm currently trying to get Qt to accept a patch to optionally do hybrid CRT linking

I'm not exactly delighted to see this complexity spreading throughout the ecosystem. (This is the first I've heard about it. We have an ancient deprecated macro, which I will not name here, that accomplished something very similar to this, that I've wanted to remove for over a decade.)

[patstew]

That's a shame, thanks for the reply.

My problem is I'm trying to make a library that has an extern "C" API but uses a lot of new C++ internally, and people keep trying to dynamically load it into things like their own python.exe that use an old bundled vc runtime, ignoring either one I bundle or the system one, which then blows up. On the other hand I was trying to avoid making one monolithic binary because it makes LGPL compliance with my dependencies painful. This hybrid linking seemed to thread the needle between the two, preventing the user from using the wrong runtime while allowing me to distribute multiple DLLs. I guess the only reason it's not caused severe doom yet is that I'm not passing much more than string& and fs::path& from the STL between my library and its deps. I don't suppose there's any other option I'm missing for having my own (namespaced?) STL that's independent from whatever the host program does but is safe to share with my own bundled dependencies?

[StephanTLavavej]

Sorry, we don't support anything like that.