[vlc-devel] UCRT support in MinGW-w64
martin at martin.st
Fri Nov 22 09:24:12 CET 2019
On Thu, 21 Nov 2019, Stephen Kitt wrote:
> I’m the maintainer of the MinGW-w64 toolchain in Debian. I believe VLC uses
> that for its Windows builds; is that correct?
> I’m wondering what your thoughts are regarding UCRT support. Currently the
> MinGW-w64 toolchain in Debian targets MSVCRT by default; this can be
> overridden by rewriting spec files, but the result isn’t entirely
> satisfactory since the GCC DLLs still use MSVCRT.
Such a solution isn't generally enough; not only do the GCC DLLs (libgcc
and libstdc++) still use msvcrt, but statically linking either, in
particular libstdc++, will fail, as the object files in the static library
were built with headers targeting msvcrt, which doesn't work if linking
the final exe/dll against ucrt.
And for the case if the prebuilt DLLs use a different CRT; that could be
fine if there's no sharing of CRT data structures (file descriptors, FILE*
handles, etc) across the DLL boundary. I don't know for sure if libstdc++
does that or if none of those ABI details leak through the DLL interface.
Within mingw-w64, we've tried to make sure that libmingwex.a should work
with both msvcrt and ucrt, but that's about as far as the object file
compatibility goes. I think, but haven't verified, that libgcc doesn't do
anything particularly fancy, so a static build of that might work fine
with either crt.
So for simple C code that doesn't link to anything prebuilt fancy, one can
in principle choose at build time just by setting the right msvcrt version
defines for all built objects (since a couple months, the recommended way
for hardcoding the version is to either do -D_UCRT or
-D__MSVCRT_VERSION__=0), and linking with either -lucrt or -lmsvcrt-os;
then you know what you get regardless of which one was the toolchain
> So I’m pondering switching the default to UCRT, to better match what
> Visual Studio does nowadays, and allow targeting UWP without too many
The main gotcha regarding this, is that UCRT isn't available out of the
box before Windows 10, but it requires installing a separate
redistributable. With MSVC, this isn't quite as much of an issue as you
can choose to statically link the CRT there, but that's not possible in
And I've understood that this is a blocker for using UCRT for the VLC
> Another possibility, albeit rather more complex on my end, would be to add -m
> options to GCC, with multiple builds of the DLLs. That would also allow me to
> provide DW2 and SJLJ support for Win32.
I'm afraid something like that is necessary, if you want to allow the end
user to choose.
More information about the vlc-devel