Thank you very much, Biswapriyo Nath and Martin Storsjö! I ask because in GLib we have to work around a MSVCRT issue. Basically, the _wspawn*e functions from the MSVCRT are not thread safe, see https://gitlab.gnome.org/GNOME/glib/-/issues/2509 for more informations. As such we have to add a mutex protecting _wspawn*e calls. That doesn't fix the issue completely, as other modules in an application might call _wspawn*e functions, but it's still a good measure.
I was contemplating about adding a mutex only if using the MSVCRT-based toolchain. I guess I can include a CRT header and test for #if !defined(_UCRT) && !defined(GLIB_STATIC_COMPILATION). Or maybe the mutex can be added to the MinGW-w64 headers? Out of curiosity, by running the echo | gcc -dM -E - command from the MSYS2 MinGW UCRT x64 shell I can see: #define __MSVCRT__ 1 Is that macro necessary in a UCRT-based toolchain? Thanks again for your help Luca Il giorno gio 23 giu 2022 alle ore 15:06 Martin Storsjö <[email protected]> ha scritto: > On Wed, 22 Jun 2022, Luca Bacci wrote: > > > As per the title, say I compile a static library archive using > > mingw-w64-ucrt, can I use that archive with mingw-w64-msvcrt? (or > viceversa) > > Indeed, as Biswapriyo said, in general, you can't mix. > > In practice, mixing them does work in many cases (so if you try, you might > not notice immediately), but in general it can't be relied on and assumed > to work. > > > If interop is not supported, is there a way to determine if gcc is > > compiling for MSVCRT or UCRT, e.g. using a macro? > > If you include a CRT header, "_UCRT" is defined if the headers target > UCRT. > > // Martin > > > > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
