Fix GNU toolchain builds #166
Conversation
|
|
| @@ -22,7 +22,7 @@ extern "system" { | |||
| ) -> u32; | |||
| } | |||
|
|
|||
| #[link(name = "onecore")] | |||
| #[link(name = "windowsapp")] | |||
There was a problem hiding this comment.
Do you know why the GNU toolchain accepts windowsapp and not onecore? Both are just umbrella libs. And yes, I'm planning to avoid the problem with these libs with #142. This change is ok, but in general I'm unconfortable making a change that we don't verify in the build. Is there a way to validate both MSVC and GNU?
There was a problem hiding this comment.
The reason is because there is libwindowsapp.a in the MinGW-w64 toolchain but no libonecore.a - as simple as that :)
I can play with the tests to see if I can compile them for GNU, but the reason is quite similar - there is no libcoremessaging.a in the GNU toolchain.
There was a problem hiding this comment.
The approach in #142 is definitely much better.
There was a problem hiding this comment.
We can probably simplify the tests to avoid the additional link dependencies. The concern I have with #142 is that I don't know whether that will work with something other than the MSVC lib tool.
There was a problem hiding this comment.
The only usage of coremessaging is for CreateDispatcherQueueController. This is in composition.rs tests. I'm not sure how this can be simplified tbh, but we could probably load this function dynamically instead?
There was a problem hiding this comment.
The approach in #142 should work for MinGW-w64 just fine from my understanding. What you need is a *.def file and the dlltool that will generate a *.a file based on it. To automate *.def file generation you could also use gendef first. Example (from here):
gendef.exe csfml-graphics-2.dll
dlltool.exe -d csfml-graphics-2.def -D csfml-graphics-2.dll -l libcsfml-graphics.a
These tools are part of MinGW-w64 toolchain and should be available on all platforms.
There was a problem hiding this comment.
Let's take this change for now and deal with the tests separately. It would be nice to have a simple LoadLibrary/GetProcAddress helper.
This PR fixes the GNU toolchain (-pc-windows-gnu) builds for the apps that use winrt-rs.
Note that it is still not possible to build all the tests in winrt-rs itself with the GNU toolchain, but with MSVC toolchain all the tests pass.
It is probably a temporary workaround, though I see that the TODO to dynamically load the APIs from OneCore has been removed.