New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compile fails with mingw due to cludgy defines #74
Comments
libs affected for me were: |
Uh oh. I'm aware of this silly define, and here I'm attempting to The MinGW build on the CI compiles the plugins fine and I'm not aware of any similar reports, so this has to be either new in recent MinGW or you have something special in your build that defines it again after it's undef'd. What's the MinGW version you have? @williamjcm are you running into this issue as well? |
Thank you for your fast replies I'm not sure if this is good enough for the mingw version
It looks like windows.h gets included after the interface undef.
|
Nope. Though at the same time, I don't use any of the mentioned plugins. EDIT: Also, IIRC, the magnum-plugins package in the MSYS2 repos has those plugins enabled, but it builds without issues. |
Argh, I have no idea why there would be a difference 😅 If I can't reproduce this, I can't reliably fix all occurences. I can probably manage to fix this for DrFlac by defining @DJQuardaboff if you add |
The magnum-plugins package in the MSYS2 repos is fine because it's v2019.01. The struct with member Command line:
Adding
(rpc.h is where the actual
It compiles even when commented out, so the flag
|
Nope, it's 2019.10. However, I noticed the magnum-integration package is still 2019.01, so I'll mention that to the repos' maintainers. |
Yes, my bad I didn't refresh the pacman database. |
@DJQuardaboff ah, so if I understand correctly, the issue disappears when updating to latest? :) I'll add |
The problem is still there if compiling v2019.10 on mingw, but the mingw pacman has precompiled binary for it. My specific problem is solved. |
Can you upload your CMakeCache.txt from the build directory where the compilation fails? Or the whole thing, including cloned sources? I'll try to investigate. |
https://drive.google.com/drive/folders/1gXT692jvbpmFkk-9Zcm6F51xCCmW8F9U?usp=sharing
ps. I tried install a fresh copy of mingw to make sure I wasn't crazy and it didn't play nice with cmake... :( |
Yay, thank you! This helped me to finally reproduce -- https://ci.appveyor.com/project/mosra/magnum-plugins/build/next-1030/job/72472c9idmuweyaw ... somehow this happens only when the plugins are built static (and I forgot to ask about that before 😅). Investigating why, will push a fix once I know what's to blame. |
With 5aca223 I added static builds of plugins to the CI, which uncovered two more unrelated issues that are also fixed now (:sweat_smile:). Then, mosra/corrade@b70e4f9 defines So current master should have everything fixed again. @DJQuardaboff thanks for your patience and the extensive investigation you did -- it helped a lot. Sorry it took me ages to fix :) If you can confirm everything is building properly again, I'll be grateful. Thanks again! |
...!! yes! compiles! |
Usually, if a patch stays in the repo, it's relevant. And in this particular case, it's still used in the PKGBUILD, so, it is. |
Yes, but commenting the thing out didn't break anything ... and compiling vanilla unpatched libjpeg-turbo on mingw (on magnum's CI) works as well, so I have my doubts. |
Huh. I'll try mentioning it on MSYS2's Gitter room, then. |
Many importers and converters include files which include
windows.h
. In mingw, windows.h (and other files) contain a line like:#define interface struct
...
oof
It obviously does not work well with
Corrade::PluginManager::Implementation::StaticPlugin
inAbstractManager.h
, which contains aconst char* interface
, and when referenced produces this error for me:I temporarily solved it by slapping an
#undef interface
right before theCORRADE_PLUGIN_REGISTER
.The text was updated successfully, but these errors were encountered: