Fix lime.ndll build on MinGW #1660
Conversation
tobil4sk
force-pushed
the
mingw-fixes-8.2.0-Dev
branch
from
5ba7e8e to
c7c386d
Compare
|
I separated out some of the commits into #1661, because with those commits it's already possible to cross compile projects with mingw with a precompiled lime.ndll. |
|
I'm interested in testing this build! Could you offer any links to the new precompiled minGW version of lime.ndll? If not, I can look into building from source, but it might be a while. |
Hi sorry, I haven't uploaded the precompiled lime.ndll anywhere. Building from source isn't too complicated as long as you have mingw set up, when I have a look at this again I can try to provide some proper instructions for how to do this. I should have provided instructions originally in the PR, sorry. Once I have a look again I could probably upload a copy of the ndll here as well. Just a heads up, I managed to get things compiling but the build wasn't really working. When I tried to run a project with the mingw ndll there was no window showing up unfortunately. This will require more investigating to figure out what exactly is wrong. In the meantime I have just been building my actual project code with mingw (with #1661 and the git version of hxcpp) but using the regular Windows lime.ndlls instead of compiling my own mingw copy. |
I'll give that a try! Thanks again for all of the work you've put into this build. |
|
When trying compiling my app (with this library), I get an error: Do you know what I may have to do in order to get the windows.h header file to be included? I'm not sure if I haven't linked minGW or if it's otherwise not set up correctly. Edit: I used this guide to manually set some of my paths. I cannot compile to 32-bit (he |
tobil4sk
force-pushed
the
mingw-fixes-8.2.0-Dev
branch
from
35d6050 to
75a0488
Compare
tobil4sk
force-pushed
the
mingw-fixes-8.2.0-Dev
branch
from
75a0488 to
33f616e
Compare
tobil4sk
force-pushed
the
mingw-fixes-8.2.0-Dev
branch
from
33f616e to
a475216
Compare
I figured out that this issue can be worked around by avoiding With current hxcpp, when cross compiling from linux it is necessary to rebuild with This compiles properly now, and also runs successfully from my testing! |
|
Wondering whether this should be targeted at develop or 8.3.0-Dev. On one hand, mingw is already partially supported, and this just makes that support full. On the other hand, it requires updating cairo (1.18.2 to 1.18.4) and could be considered a new feature. |
|
If it were me, I'd probably put it into 8.3.0-Dev. I tend to avoid updating submodules on develop unless an operating system update leaves us no choice (I recently had to do that for a few because GitHub Actions updated macOS/Xcode and builds were failing) or if I need to fix a regression from a previous submodule update. |
When cross compiling from Linux, header names are case sensitive unlike on Windows.
This causes issues on mingw, and is no longer needed since openal now uses std::isfinite (c++11) instead of isfinite. kcat/openal-soft@3ae1c78
With mingw, converting from char* to _bstr_t calls ConvertStringToBSTR which is not defined by mingw. Creating all strings from wchar* avoids this issue. comsuppw.lib is also unavailable on mingw, and we need to add wbemuuid.lib manually as the #pragma comment(lib, ...) in System.cpp is only respected by MSVC. Adding bstr_t explicitly rather than relying on implicit conversion also avoids gcc warnings here.
When cross compiling, the default target is set as neko in HXProject, so we can't assume that rebuild will always be cpp.
`wbemuuid.lib` must be linked explicitly, since #pragma
comment(lib, ...) only works with msvc.
`comsuppw.lib` does not exist in mingw.
`no_shared_libs` must be set for mingw to ensure the standard library
and other libraries are linked statically.
`.lib` must be replaced with `${LIBEXT}` so that it resolves to `.a` on
mingw.
MSVC links this automatically due to a #pragma in curl's source code, but other compilers require it to be added explicitly.
tobil4sk
force-pushed
the
mingw-fixes-8.2.0-Dev
branch
from
775bece to
3eee8f1
Compare
|
develop is currently on cairo 1.18.2, which turns out to be sufficient to compile lime with mingw, so I have removed the cairo 1.18.4 bump from this PR. The remaining changes are minor patches so I think they should be suitable for develop. I have added a mingw build to ci, just so we can confirm that it builds without errors. It is uploaded as an artifact to the workflow run, but it doesn't go in the actual lime release. |
3 participants
Fixes some issues to allow compiling lime.ndll with MinGW.
I'm not too sure what the best way to deal with the System.cpp situation would be.