wxWidgets-3.2.4 non-backwards compatibility with 3.2.2.1

[Mike Rossiter]

WINDOWS ONLY
I have a dll plugin for OpenCPN that is compiled with wxWidgets-3.2.4.

This plugin installs and runs on a version of OpenCPN (5.9.x) compiled with wxWidgets-3.2.4. So far so good.

The plugin fails to install and run on a version of OpenCPN (5.8.4) compiled with wxWidgets-3.2.2.1.

This wxWidgets-3.2.2.1 module has missing imports:
C:\Program Files (x86)\OpenCPN 5.8.4-0+1637c28\wxbase32u_vc14x.dll

We want the plugin to run on OpenCPN 5.8.4 and the upcoming 5.9.x and want to upgrade to using wxWidgets-3.2.4. Is there any workaround to achieve this, apart from compiling with wxWidgets-3.2.2.1. That version runs on both OpenCPN 5.8.4 and 5.9.x

[Gunter Königsmann]

The same problem arises with every audio filter plugin that comes with a gui, nonetheless which gui toolkit it was compiled with: All that was compiled with the same toolkit has to be compiled with the same version of said toolkit.

[Mike Rossiter]

On Saturday 24 February 2024 at 11:12:22 UTC Gunter Königsmann wrote:

The same problem arises with every audio filter plugin that comes with a gui, nonetheless which gui toolkit it was compiled with: All that was compiled with the same toolkit has to be compiled with the same version of said toolkit.

 The same issue does not seem to arise on Debian or Mac.

[Mike Rossiter]

From the debug log when trying to load the plugin:

`12:31:27.668   ERROR dlmsw.cpp:167 Failed to load shared library 'C:\Users\rasba\AppData\Local\opencpn\plugins\ShipDriver_pi.dll' (error 126: The specified module could not be found.)`

[Gunter Königsmann]

Might the problem be that the application and the plugin are compiled with different variants of wxWidgets (unicode, debug, monolithic,...), a different compiler (mingw vs. msvc) or wxWidgets with different modules enabled?

[Vadim Zeitlin]

On Sat, 24 Feb 2024 02:26:25 -0800 (PST) Mike Rossiter wrote:

MR> I have a dll plugin for OpenCPN that is compiled with wxWidgets-3.2.4.

You need to set wxABI_VERSION=30202 when building using 3.2.4 headers to
ensure ABI compatibility with 3.2.2, see

https://docs.wxwidgets.org/latest/overview_backwardcompat.html

Alternatively, just build your plugin using 3.2.2 headers.

MR> This plugin installs and runs on a version of OpenCPN (5.9.x) compiled with
MR> wxWidgets-3.2.4. So far so good.
MR>
MR> The plugin fails to install and run on a version of OpenCPN (5.8.4)
MR> compiled with wxWidgets-3.2.2.1.
MR> [image: dependencies2.jpg]
MR> <https://forums.wxwidgets.org/download/file.php?id=8510&mode=view>
MR> This wxWidgets-3.2.2.1 module has missing imports:
MR> C:\Program Files (x86)\OpenCPN 5.8.4-0+1637c28\wxbase32u_vc14x.dll

It would have been useful to show _which_ imports are missing.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
https://www.tt-solutions.com/

[Mike Rossiter]

Thanks Vadim ...

Will try setting wxABI_VERSION=30202

VZ> It would have been useful to show _which_ imports are missing.

Dependencies did not show the missing imports. Not sure how else to find these.

[Vadim Zeitlin]

On Sat, 24 Feb 2024 10:57:32 -0800 (PST) Mike Rossiter wrote:

MR> VZ> It would have been useful to show which imports are missing.
MR>
MR> Dependencies did not show the missing imports. Not sure how else to find
MR> these.

Normally they should be shown (with a red icon) in the list of imports,
perhaps you just didn't scroll far enough?

[Mike Rossiter]

Dan Dickey has tracked the problem down to the define wxHAS_RVALUE_REF. Not present in wxWidgets-3.2.2.1, I think.

Transcript of our conversations on the subject is attached.

[Vadim Zeitlin]

On Sun, 25 Feb 2024 07:15:35 -0800 (PST) Mike Rossiter wrote:

MR> Dan Dickey has tracked the problem down to the define wxHAS_RVALUE_REF. Not
MR> present in wxWidgets-3.2.2.1, I think.

Hello,

Thanks for tracking this down! The important part is this one:

> The import name shipdriver_pi.dll is seeking is "(__declspec(dllimport) public: class wxString & __thiscall wxString::operator=(class wxString &&))".

and it shows that we must be exporting wxString move assignment operator from the 3.2.4 DLL but (of course) not from 3.2.2 one, where it hadn't been defined.

I have to admit that I don't understand why isn't the compiler inlining this (very simple) function, as I'd expect it to, my thinking when backporting move-related changes to wx 3.2 was that they should be ABI-compatible because all the functions should be always inlined, but this clearly isn't the case and so we have to fix it.

My proposed fix is in https://github.com/wxWidgets/wxWidgets/pull/24357 and your problem should be fixed if you

1. Cherry pick the first commit from it (https://github.com/wxWidgets/wxWidgets/pull/24357/commits/54abbb3fc0b5563ef381e503f3791a4a60613d6d)
2. Define wxABI_VERSION=30202 when building your code.

Please let me know if this works for you, TIA!

[Mike Rossiter]

The fix works fine.

Made the change to defs.h in the binaries. No need to recompile wxWidgets.
Used set CL=/DwxABI_VERSION=30202 %CL% in my .bat file.

Dan used this in the cmake configuration: -DCMAKE_CXX_FLAGS="/DwxABI_VERSION=30202 /EHsc /MP /DWIN32"

Many thanks.

[Vadim Zeitlin]

On Mon, 26 Feb 2024 00:59:39 -0800 (PST) Mike Rossiter wrote:

MR> The fix works fine.
MR>
MR> Made the change to *defs.h* in the binaries. No need to recompile wxWidgets.
MR> Used set CL=/DwxABI_VERSION=30202 %CL% in my* .bat* file.
MR> Dan used this in the cmake configuration: -DCMAKE_CXX_FLAGS="/DwxABI_VERSION=30202
MR> /EHsc /MP /DWIN32"
MR> Many thanks.

Just to close this thread, this fix was merged into 3.2 branch in Git and
will be part of 3.2.5.

Thanks again for reporting this issue!