On Thu, 10 Feb 2022, Björn Schäpers wrote:

Am 10.02.2022 um 05:06 schrieb Thiago Macieira:
On Wednesday, 9 February 2022 16:35:00 PST Björn Schäpers wrote:

What would be the best way for that? I don't think you want a #if
defined(Q_CC_MSVC) || defined(_UCRT), or do you?
No, an #ifdef _UCRT should suffice.

I'm not sure I understood correctly. Should there only be an #ifdef _UCRT? Does MSVC also define that? I couldn't find anything that suggests that.

It's not MSVC itself that defines _UCRT, but their headers do - vcruntime.h defines it. So yes, checking for _UCRT should be enough for detecting such a CRT for both MSVC and mingw, in general.

(For other features that are new in UCRT, there's no guarantee that all of them are hooked up in mingw-w64 headers yet though.)

  Are there any plans to adapt to UCRT MinGW?
Once it's officially supported by upstream, with default toolchain builds,
we
should switch.

What is upstream in this case? As far as I can see in msys2 they're heavy working on getting everything (64 bit) to UCRT.

Indeed, official releases regarding mingw-w64 toolchains is a very fuzzy area.

mingw-w64 only formally is distributed as source. There used to be someone's binary toolchain builds that were uploaded on sourceforge in the mingw-w64 project (in a "personal builds" folder) that often were seen as the official ones, but those builds stopped when that person stopped producing them (around GCC 8 I think?).

But there's really no single canonical build of it, mingw-w64 is a source distribution that anyone can configure/bundle/build as they like.

(Those releases also were mainly labelled by the GCC version included, which often is mistaken as the mingw-w64 version - which makes things much more confusing when declaring what version of mingw-w64 has complete enough headers for feature X or Y.)

IIRC Cristian Adam also has forked this and is producing new similar builds, at https://github.com/cristianadam/mingw-builds/releases. (I don't think those are available configured with UCRT though.)

// Martin
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to