MinGW GCC support

[mauriceackel]

Hi there,

I'm currently trying to use the cppwinrt bindings in a project which I'm compiling with MinGW GCC.

First, I added the path to the cppwinrt headers from the Windows SDK to my include path (i.e. C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\cppwinrt)

When I try to include some winrt header now, the compiler complaints about a missing header (i.e. <experimental/coroutine>). From my research, this language feature is only available experimentally in C++17 and can be enabled in the clang complier using the -fcoroutines-ts flag. (It is also available in MSVC, I thin there it is compiler flag /await).

I was not able to find anything about this experimental support in GCC. However, MinGW supports GCC 10 which in turn supports C++20 and has support for coroutines. To enable this, we have to tell the compiler to use c++20 (i.e. -std=gnu++20) and additionally set the compiler flag -fcoroutines. As a result, the coroutine header will be available.

As base.h only includes <experimental/coroutine>, I changed the include to #include <coroutine>. When I tried to compile again, the compiler did no longer complain about a missing headers or a missing compiler flag. However, now I get a huge amount of compile errors which I have attached in a log file.

At this moment I'm pretty much clueless how to continue or if this is even possible using MinGW GCC. Any insights and help is much appreciated. Thanks!

compile.log

[sylveon]

Try using the headers generated by cppwinrt.exe from the NuGet package, as those have been updated for C++20.

[mauriceackel]

Hi @sylveon, thanks for pointing this out. I created the winrt headers using the cppwinrt.exe now and tried again. However, there are still a lot of errors.

A huge amount of them seem to be related to symbols not being declared (in a certain scope?). For example: /Windows.UI.Composition.2.h:355:136: error: 'take_ownership_from_abi' was not declared in this scope. There are several of these errors along with some others.

I provide a somewhat less cluttered list of errors below.

Are there maybe any additional headers I have to include in order to make the winrt headers compile correctly?

compile.log

[sylveon]

GCC is not officially supported, but I'm still surprised at some of these errors. For example take_ownership_from_abi is declared in winrt/base.h, which should be already included by winrt/Windows.UI.Composition.2.h:

cppwinrt/strings/base_meta.h

Lines 10 to 11 in d056690

	struct take_ownership_from_abi_t {};
	inline constexpr take_ownership_from_abi_t take_ownership_from_abi{};

The memcmp error is probably just because std:: was omitted.

[mauriceackel]

@sylveon Yes it is strange indeed! I just want to let you know that the results above ware created with the old cppwinrt.exe version (from the comment thread in the other issue). However, I just tried it again with the headers from the new cppwinrt.exe and have similar errors again. I will investigate further in the next days and give some more insights into this. Maybe there is a way to make this work in GCC 🤞

[mauriceackel]

Hey everyone, I want to share some insights with you regarding my investigations in GCC compatibility:

1. GCC does not support __pragma used here

• Instead, GCC supports _Pragma as explained here
• I tested this by adding a new condition, that either uses __pragma or _Pragma depending on which compiler is used and it seems to be working
• An important note is, that the argument of _Pragma has to be wrapped in quotes (and as a result, all the internal quotes have to be escaped)
• This addition fixes a lot of the compile errors, especially the ones regarding 'take_ownership_from_abi' was not declared in this scope` and alike
• Example: #define WINRT_IMPL_LINK(function, count) _Pragma("comment(linker, \"/alternatename:_WINRT_IMPL_\" #function \"@\" #count \"=_\" #function \"@\" #count)")

2. I needed to use the following compiler flags for GCC 10:

• -std=c++20: Use C++20
• -fcoroutines: Enables coroutine support

3. I had to add std:: to the nullptr_t usage here and here
4. Had to include the Windows header to make several things work:

• #include <Windows.h>: Required for _InterlockedIncrement64, _InterlockedDecrement64, _ReadWriteBarrier, (...?)

Open Issues

1. _InterlockedCompareExchange128 should be declared in <intrin.h> but the compiler still complaints about not finding the symbol. This seems to be in 64bit related issue. The corresponding code is here
2. I need to use __cpp_impl_coroutine instead of __cpp_lib_coroutine here (and perhaps everywhere else it is used) as for some reason the latter is not defined.
3. I get error: could not convert 'winrt::clock::from_sys<std::chrono::duration<long long int, std::ratio<1, 1000000000> > >(std::chrono::_V2::system_clock::from_time_t(time))' from 'time_point<[...],duration<[...],ratio<[...],1000000000>>>' to 'time_point<[...],duration<[...],ratio<[...],10000000>>>' for the function definition here
4. I get error: no matching function for call to 'to_chars(char*, char*, float&, std::chars_format)' and error: no matching function for call to 'to_chars(char*, char*, double&, std::chars_format)' here

• This might be due to the reference types float& and double&?

All the above was tested in a dummy project where I only included winrt/base.h the headers were generated using the cppwinrt.exe in version 2.0.210930.14.

@sylveon Is there any interest in supporting GCC? I guess what I'm asking is "Should I look further in to this with the result of potentially creating a PR with your help?"

[mauriceackel]

Ok after a bit more research I think there is a much bigger underlying issue and that is that MinGW ships its own (adapted) headers for windows functionality and I'm pretty sure, that they are not complete, which I believe is the reason for some errors like 'winrt::Windows::Foundation::Numerics::float4' has not been declared.. I'm pretty much desperate right now, as I'm unable to build my entire project using MSVC due to its dependencies but also unable to build it using MinGW...

[kennykerr]

Thanks for looking into this. As you illustrated, adding support for a new compiler is quite an undertaking. Unfortunately, I don't have the bandwidth to take this on right now. As it is, we don't have any CI build support for Clang so we would have to first figure out how to actually test not just VC but Clang before adding another compiler. Once we can actually run all tests with all compilers then I would be happy to consider a contribution to support GCC.

[kennykerr]

I'm pretty much desperate right now, as I'm unable to build my entire project using MSVC due to its dependencies but also unable to build it using MinGW...

You may also want to consider compiling them separately and then linking them together using either a LIB or DLL.