>> Or maybe the mutex can be added to the MinGW-w64 headers?

>Hmm, I'm not sure - in one sense, mingw-w64 should just expose the
>platform as accurately as possible, while we do try to fix some of the
>sharper edges (from a portability point of view too)

Yes, that makes sense, and afterall the issue is in the system-provided
MSVCRT. On the other hand, adding a little stub in the toolchain libs would
solve the issue for all projects (GLib, Python, ...), and would also solve
it completely, contrary to working around it inside GLib.

Let me know how you maintainers would like to proceed, either decision is
worthy of respect :-)

Luca

Il giorno gio 23 giu 2022 alle ore 16:29 LIU Hao <[email protected]> ha
scritto:

> 在 2022-06-23 21:38, Luca Bacci 写道:
> >>
> >> #define __MSVCRT__ 1
> >>
> >> Is that macro necessary in a UCRT-based toolchain?
> >>
> >>
> If you have GCC source you may have a look at 'gcc/config/i386/mingw32.h',
> where there is
>
>      builtin_define ("__MSVCRT__");
>
> So it's defined unconditionally, no matter whether it is UCRT or MSVCRT
> that is being linked
> against, or even when there is no CRT at all such as when `-nostdlib` is
> in effect.
>
>
> This macro was added in 3fafc2f66579e8baac5d27dd66e3813e05c0c0b6, roughly
> 24 years ago. I am not
> clear about how many people there are, who check for it, but if any, they
> of course don't expect
> removal of it.
>
>
>
> --
> Best regards,
> LIU Hao
>

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to