search

Rasbats / shipdriver_pi

Almost a simulator
GNU General Public License v3.0
3 stars 21 forks source link

Fix wrong ABI for OpenCPN 5.8.4/wxWidgets 3.2.2.1 (#584) #585

Closed leamas closed 9 months ago

leamas commented 9 months ago

Trying to get the fix from zulip into the regular build. Late here, needs testing.

leamas commented 9 months ago

rebased: Fix silly linux/macos FTBFS

Rasbats commented 9 months ago

If wxWidgets-3.2.4 is ok for linux and mac why not put -DwxABI_VERSION=30202 in Appveyor.bat?

leamas commented 9 months ago

If wxWidgets-3.2.4 is ok for linux and mac why not put -DwxABI_VERSION=30202 in Appveyor.bat?

From a more formal point of view we want to stay at the ABI used by 5.8.4 for some time. Even if linux "seems" to work for now this is just a coincidence, probably because both gcc and clang inlines the function which is the culprit in this issue.

And we don't know what might happen in next wxw release. The route to keep it sound seems to be to add wxABI_VERSION=30202 also to the linux and macos builds. This is basically a noop for today, but might be helpful in next wxw update.

And then again, all this then belongs to cmake/PluginCompmiler rather than appveyor.bat. The issue about ABI is not just about WIndows, and should thus be in a single place.

To be honest I did not think much about all this, I just did it. Your question is forcing me to rethink. But after doing so I think this is the right approach so far i. e., it become right by sheer luck,

leamas commented 9 months ago

@transmitterdan reminded me about the rapidjson patch system I did some time ago. Need to look into that, back later.

leamas commented 9 months ago

Rebased: Use cmake/PatchFile.cmake instead to patch defs.h. Should be much more robust.

If you are happy with it it's ready to merge.