Re: Re[2]: wxWidgets-3.2.4 non-backwards compatibility with 3.2.2.1

FEB 22
Alec Leamas
11:27 AM
Ping?

I and Mike have windows problems: plugins linked to wxwidgets 3.2.4 can not be linked to wxwidgets 3.2.2.1 used in 5.8.4. It works when using 5.9 and hence 3.4.0.

It seems to work on MacOS and Linux, this is a windows problem.

The only thing I and Mike can see is the windows error code (127?), there is no info whatsoever why our 3.2.4 plugin does not link to OpenCPN 5.8.4/wxw3.2.2.1. If we knew which symbol(s) this is about we could perhaps work around it.

Is there any way too see more details in the failed runtime linkage between the plugin DLL and the OpenCPN 5.8.4 executable?

Mike Rossiter
11:36 AM
Alpha package works:
https://cloudsmith.io/~opencpn/repos/shipdriver-alpha/packages/
Beta package fails on 5.8.4:
https://cloudsmith.io/~opencpn/repos/shipdriver-beta/packages/

Alec Leamas
11:38 AM
I presume the alpha is using wxw 3.2.2.1, beta 3.2.4.

The basic problems is still here: What kind of mismatch causes the link failure?

Mike Rossiter
11:38 AM
I presume the alpha is using wxw 3.2.2.1, beta 3.2.4.

Correct.

Alec Leamas
11:39 AM
So, let's see if we can get some help

Dan Dickey
11:40 AM
Dependency Walker (depends.exe) should be able to tell you what you want to know.

 11:41 AM
Dependencywalker.com

Alec Leamas
11:47 AM
@Dan Dickey Thanks! At a glance, seems like the right tool. Might need some hands-on to cope with the fact the plugins are dl-loaded in runtime, assuming it's possible.

Dan Dickey
11:48 AM
I think it will watch the DLLs get loaded. It can also analyze the dll itself and tell you what symbols it wants to import. Also will tell you what symbols a dll exports.

 11:49 AM
But it’s pretty slow program. Single threaded.

Alec Leamas
11:50 AM
@Dan Dickey I don't care if it's slow as long it has some way to pinpoint unresolved deps.

Dan Dickey
11:51 AM
I haven’t tried it, but there is also https://github.com/lucasg/Dependencies

Alec Leamas
11:52 AM
@Mike Rossiter Can you make a try with this? I'm awfully short of time today... You should have depends.exe installed with VS, probably available in the VS command prompt .

Hiopefully, Dan is looking over my shoulder

Mike Rossiter
11:53 AM
Can you make a try with this?

Playing with this at the moment.

 1:05 PM
It looks like the wxWidgets-3.2.1 dll wxbase32u_vc14x.dll (in OpenCPN 5.8.4) is missing a module that ShipDriver.dll (wxWidgets-3.2.4) needs. Tested this by placing the SD3.2.4 dll in the Program Files folder of both OpenCPN 5.8.4 and 5.9.x. No module missing for 5.9.0.

 1:59 PM
dependencies.jpg


 2:02 PM
dependencies.undecorated.jpg


 3:00 PM
Wrong ... the highlights are the same for both versions of the shipdriver.dll.

Alec Leamas
4:11 PM
The highlights seems to be about C linkage rather than C++, probably not a rpoblem.

Mike Rossiter
4:18 PM
dependencies2.jpg


Alec Leamas
7:23 AM
Right. So which are these "missing imports" ?

Mike Rossiter
11:08 AM
https://docs.wxwidgets.org/latest/overview_backwardcompat.html
Tried: add_definitions(-DwxABI_VERSION=30202) in PluginCompiler.cmake without success.

Dan Dickey
11:57 AM
@Mike Rossiter I think the build of wxWidgets might be the issue. I'm not sure but we should be using wxWidgets built with this in setup.h:

#define WXWIN_COMPATIBILITY_3_0 1
Mike Rossiter
12:23 PM
@Dan Dickey I normally use the cache of binaries. Now making a build of wxWidgets-3.2.4 with your suggestion to test this.

Dan Dickey
1:53 PM
I think the binaries that wxWidgets provides have this flag set 1.

 1:53 PM
But also, they have indicated they will soon change to 3.1 compatibility mode which will break some older code.

Mike Rossiter
5:22 PM
No progress here!

Dan Dickey
3:20 AM
I created a minor PR against shipdriver tonight. It build ok and created a tarball pushed to CloudSmith. I imported that tarball into my local win32 build which is linked to wxWidgets v3.2.4. No errors and no linkage problems. Plugin seems to run ok.

I did notice that there is some synchronization problem with @Alec Leamas opencpn libs submodule. I had to hack around that. Could that be the ultimate source of the issue?

Alec Leamas
9:51 AM
I imported that tarball into my local win32 build which is linked to wxWidgets v3.2.4. No errors and no linkage problems. Plugin seems to run ok.

... whcih is good. However, the actual problem here is linking plugins to the existing OpenCPN 5.8.4 wxw 3.2.0 libs. Have you tried this?

Mike Rossiter
10:57 AM
Have had responses from the wx-users group:
https://groups.google.com/g/wx-users/c/Edcc3WPL7sc
Tried setting wxABI_VERSION=30202 in a number of places without success. Where should this be set?

Bottom line: Windows is the outlier. Do we accept using wxw 3.2.2.1 libs for Windows only plugins, which will work with OpenCPN 5.8.4 and 5.9.x?

Dan Dickey
11:10 AM
I thought appveyor was the method to create problematic plugins. Are you saying that shipdriver built by CI will run in O built with latest wx 3.2.4 but same plug-in will not run in O built with wx 3.2.0?

Alec Leamas
11:12 AM
More or less so. To be exact: plugins built with current setup w 3.2.4 works with OpenCPN 5.9 but not OpenCPN 5.8.4

 11:12 AM
... and this is a windows only problem.

 11:14 AM
The problem occurred when we updated wxWidgets to 3.2.4

Dan Dickey
1:16 PM
This smells like some kind of compiler bug or maybe a misuse of wxString. Yes, I know compiler bugs are rare.
The import name shipdriver_pi.dll is seeking is "(__declspec(dllimport) public: class wxString & __thiscall wxString::operator=(class wxString &&))". There is no such function within the declared operators of wxString class in the wxWidgets sources. It's as if the compiler made up this weird function name when building against wXwidgets 3.2.4. It's unlikely wxWidgets would export such a function anyway.

Alec Leamas
1:22 PM
At last! So many thanks for sorting this out. At last we have an indication of a missing symbol.

That symbol is a move operator, similar to std::move., the usage is probably implicit. I guess we could either try to find where the usage originates, or simply add the missing move copy operator

 1:33 PM
Perhaps we could bring this this to the wxWidgets forum, now that we have a hint about what's going on?

Dan Dickey
2:20 PM
Well, I can't explain how, but wX3.2.4 wxbase32u_vc14x.dll exports that exact symbol. But what code produced it eludes me so far. Still looking.

Alec Leamas
2:25 PM
hm... So we are using a symbol only available in 3.2.4. This is per se nothing strange, backwards compaitble does mean that new symbols cannot be added.

This then also means that the actual use of this symbol has been added after 5.8.4 (?)

If so, it shoild be possible to bisect the commit which added this reference, I guess.

Dan Dickey
2:27 PM
Here I found the function in string.h:

#ifdef wxHAS_RVALUE_REF
    // move from another wxString
  wxString& operator=(wxString&& stringSrc) wxNOEXCEPT
  {
    m_impl = std::move(stringSrc.m_impl);
#if wxUSE_STRING_POS_CACHE
    InvalidateCache();
    stringSrc.InvalidateCache();
#endif // wxUSE_STRING_POS_CACHE

    return *this;
  }
#endif
 2:31 PM
It's probably due to the wxHAS_RVALUE_REF define. Maybe in 3.2.0 this symbol is undefined?

Mike Rossiter
2:36 PM
Great stuff.
Quick search in 3.2.2.1 source code: wxHAS_RVALUE_REF not found.
Found in 3.2.4.

 2:41 PM
In 3.2.4 source code: include/\wx\defs.h:

/* same for more C++11 keywords which don't have such historic baggage as
   override and so can be detected by just testing for C++11 support (which
   still requires handling MSVS specially, unfortunately) */
#if __cplusplus >= 201103L || wxCHECK_VISUALC_VERSION(14)
    #define wxHAS_MEMBER_DEFAULT

    // Rvalue references are supported since MSVS 2010, but enabling them
    // causes compilation errors on versions before 2015
    #define wxHAS_RVALUE_REF

    #define wxHAS_NOEXCEPT
    #define wxNOEXCEPT noexcept
#else
    #define wxNOEXCEPT
#endif
Alec Leamas
2:44 PM
OTOH, it was long time ago we used VS2015. Or?

My gut feeling is that wxHAS_RVALUE_REF somehow reflects capabilities of the compiler. If so, these capabilities are probably available as long as we are using C++11. But on thin ice here.

This might happen if compiling something like  foo = std::move(bar) where bar is a wxString. Generally, using move here is considered an optimaztion compared to a plain assignment which involves refcounting stuff.

 2:47 PM
A really simple try would be to add the implementation above to our own sources. It would then be used on both 5.8/wx3.2.2.1 and 5.9/wx3.2.4 in favor of the wxWidgets library implementation, right?

Dan Dickey
2:53 PM
A simpler thing might be to undef this preproc directive when building against 3.2.4 if we want to be compatible with 3.2.0.

I think this preproc directive was introduced as wxWidgets drops compatibility with older MSVC compilers.

Alec Leamas
3:00 PM
Yes, I agree: wxHAS_RVALUE_REF is about handling older compilers while moving on using stuff which requires more modern compilers.

However, is this really the issue her? IIRC, we used the precompiled binaries from wxWidgets website: https://github.com/wxWidgets/wxWidgets/releases/tag/v3.2.2.1

I don't see any reason the compiler used should be too old (?)

 3:03 PM
Add ing the operator could be done while still using the official binaries; re-compiling means using our own.

IMHO we should talk to the wxWidgets people, nodably vadz, before making decisions how to handle this

Dan Dickey
3:03 PM
I agree. It is probably the simplest thing to just provide this function locally for plugins that need it to be compatible with 3.2.0.

Mike Rossiter
3:04 PM
Would you like me to add this conversation to my thread on the wx-devs group?

Alec Leamas
3:05 PM
@Dan Dickey In any case you deserve a beer for sorting this out. It's a shame it has to be virtual...

Mike Rossiter
3:05 PM
Agreed.