[vlc-devel] UCRT support in MinGW-w64

[Stephen Kitt]

Hi Martin,

On Fri, 22 Nov 2019 11:50:18 +0200 (EET), Martin Storsjö <martin at martin.st>
wrote:
> (Re-sending this reply, as I learnt you aren't subscribed to the list)

Sorry, I forgot to mention that!

> 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.

Yes, that’s what I was thinking of; thanks for spelling it out.

> 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 
> default.

Ah, good to know, I’ll have to try that out.

> > So I’m pondering switching the default to UCRT, to better match what 
> > Visual Studio does nowadays, and allow targeting UWP without too many 
> > contorsions...  
> 
> 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 
> mingw-w64.
> 
> And I've understood that this is a blocker for using UCRT for the VLC 
> releases.

That is indeed a good point. I guess Visual Studio doesn’t bother with
pre-Windows 10 targets too much, so using that as a reference to justify
a switch to UCRT isn’t necessarily appropriate!

> > 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.

Yes, that’s what I’m looking at now.

Thanks for the feedback,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191124/629fb835/attachment.sig>