Update the mingw32uwp wrapper libraries #127
Conversation
|
Forcing |
Sure
Are you sure that it is allowed to link against ucrtbase.dll in UWP mode? Because when I looked into this (2 years ago?) the App Certification Kit explicitly pointed out that it is not allowed to link against ucrtbase.dll in such apps, only the indvidual api-ms-win-crt-*.dll (and not the -private one). That's why I added I rechecked now in
I prefer We could add that define, but it doesn't really help the fact that libc++ isn't really functional if it was built originally against msvcrt.dll but you want to link against ucrt. That's why I have a check for the default CRT in https://github.com/mstorsjo/llvm-mingw/blob/master/run-tests.sh#L38-L40, and if it isn't UCRT, we just skip testing the uwp variant of the toolchain. I guess an even more correct approach would to simply leave out the -uwp frontend wrappers if the toolchain wasn't built in UCRT mode?
UWP explicitly requires you to use UCRT, so the intent of this is entirely correct. But I'm not entirely convinced that it's worth it as it doesn't fully work if it wasn't the default. |
I'm not sure yet but I will give it a try on the Xbox. I ended up looking at this because mixing ucrt and
I also did the same check. Neither are
OK
That sounds like a good idea. |
That might succeed even if it isn't allowed by a validity check (although I don't really know anything about Xbox).
Well not really. ucrtbase.dll is the physical DLL that contains the actual implementation of code, just like kernel32.dll and all that. But when targeting UWP, you aren't supposed to link directly against kernel32.dll, you link against windowsapp, which then ends up importing api-ms-win-core-*.dll. If there are functions from kernel32.dll, that aren't available in api-ms-win-core-*.dll, you can't just link against kernel32.dll because it happens to have the functions you want. The same goes for UCRT, with ucrtbase.dll vs api-ms-win-crt-*.dll (except for the -private one). If you build an UWP app with MSVC, it ends up linking against api-ms-win-crt-* only, but also vcruntime140_app.dll - but not ucrtbase.dll. Vcruntime140_app.dll isn't listed in App Certification Kit though, because it isn't a system DLL - when you build an UWP app with MSVC, this DLL gets bundled with your app. So if you build a DLL component (e.g. libvlc) for use within an app packaged by MSVC (like vlc-winrt today), linking against vcruntime140_app is the correct, and simplest, thing to do. That's where we are right now. If you don't want to package the app with MSVC and don't want to bundle vcruntime140_app.dll, you'll need to provide your own version of these functions, like |
|
Some background on the various C Runtimes available in recent MSVC: https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features and also https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/ From MSVC but from the documentation it seems it will end up using The blog post is interresting as it describes what you need to use when using But I just tried building a blank app in VS 2019 with |
|
Also there is no |
- windowsapp is the preferred library when targeting Windows 10 https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis - _UCRT ensures we use the Universal C runtime
|
I have an upcoming PoC patch for getting rid of vcruntime140_app, it's ready for posting within a few days. |
|
See https://github.com/mstorsjo/mingw-w64/commits/ucrt-app for a PoC for getting rid of vcruntime140_app.dll, in particular, mstorsjo/mingw-w64@1fdf0a5. |
|
Interresting. I also started a separate lib based on musl. Adding more CRT code in mingw-w64 means more code to maintain there. In my case it's just the musl source code where I cherry pick the files I want to build (there's no autotools/cmake/meson in there so it's easy to just add one in there without patching anything). Also IMO the libraries to include should have the same names as in MSVC so probably Maybe we should move this discussion on the mingw-w64 ML to see what others think. |
|
(just noticed some C files come directly from musl so it sounds good, apart from the naming&splitting of libs) |
Well it's not just the musl source files. If looking at what functions there are in vcruntime140_app or api-ms-win-crt-private, it's primarily a lot of windows specific functions (although mingw-w64-crt already does have a number of crt implementation files (math routines, stdio implementations, etc), so in general I don't think the maintainance of these few is a big thing in itself. The only issue is that The goal was to have all of this work out of the box by just building mingw-w64-crt, as it doesn't seem like much of a stretch from where we are today, contrary to adding yet another third party repo to the build.
In general, matching lib names with MSVC is desireable, for the cases where it makes sense, but the CRT is hooked up quite differently in mingw vs MSVC anyway. I wouldn't try naming anything of this You don't need to worry about In MSVC you normally link one toplevel library ( That lets the default be what it is today (with no compromises regarding implementation of these functions), while
I guess that'd be a good thing to do yes. I could post my PoC there and see what others think. |
windowsapp is the preferred library when targeting Windows 10, it's safe to use it with the current mingw-w64 repo
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
ucrtbase.dll is the DLL that holds the equivalent of what was in vcruntime140_app
__MSVCRT_VERSION__ensures we use the Universal C runtime