Re: [lmi] wx mismatch between versions

[Vadim Zeitlin]

On Tue, 30 May 2017 23:30:52 +0000 Greg Chicares <address@hidden> wrote:

GC> When I try to run lmi (i686, wine) I get a messagebox saying:
GC> 
GC> Mismatch between the program and library build versions detected.
GC> The library used 3.1.1 (wchar_t,compiler with C++ ABI 1002,STL 
containers,compatible with 3.0),
GC> and your program used 3.1.1 (wchar_t,compiler with C++ ABI 1002,STL 
containers).
GC> 
GC> After seeing it the first time, I rebuilt wx and wxpdfdoc from
GC> scratch, then re-made lmi, and got the same message again.
GC> 
GC> Then I removed my lmi build directory and built lmi again from
GC> scratch, and got the same message again.

 Sorry for all this waste of time, which stems from my suggestion to use
--disable-compat30 :-( I shouldn't have given it, but then I had no idea it
would result in such problems.

[..snip...]
GC> It seems odd that wx is "compatible with 3.0" even though it was
GC> configured otherwise, yet lmi isn't "compatible with 3.0". It's almost
GC> as though wx knows that I gave that option, and passes it to wx-config,
GC> but then ignores it when wx itself is built.

 I have no explanation for the observed behaviour, all I can say is that
it's definitely _not_ supposed to happen.

GC> Could it be that '--disable-compat30' is not allowed, because I'm using
GC> this older sha1sum:
GC>   wxWidgets-41045df7ea5f93e4c07c1bd846d7127a372705bd.zip
GC> (backpatched for the issue recently discussed)--i.e., is that commit
GC> incompatible with disabling 3.0 compatibility?

 I don't think anything relevant has changed since this commit.

GC> Is there any way I can debug this? Should I just remove
GC> '--disable-compat30'?

 Let me answer these questions in disorder: first, if you just want to get
rid of the problem, simply removing --disable-compat30 is perfectly
reasonable and no harm will be done by doing it.

 Second, I think it might be worth debugging this just because I'm afraid
we might run into other problems, not immediately detected by the build
configuration check, later if we don't find the reason for this one now.
Because the only explanation I see is that lmi is not using either the
correct setup.h header or the correct libraries, i.e. there really must be
a mismatch somewhere.

 To debug it, you need to check the value of WXWIN_COMPATIBILITY_3_0 in the
setup.h used when building the library by running the following command in
the wx build directory:

        $ fgrep WXWIN_COMPATIBILITY_3_0 
lib/wx/include/gtk2-unicode-3.1/wx/setup.h

Normally this should show "0". Next, you should check its value in the
installed version of setup.h, i.e.

        $ fgrep WXWIN_COMPATIBILITY_3_0 
/opt/lmi/local/lib/wx/include/gtk2-unicode-3.1/wx/setup.h

(I hope I got the path correctly, but my lmi VM is not running right now,
so sorry in advance if I made a mistake, this is the path that is part of
`wx-config --cxxflags` output). Normally this one should be 0 too: both
because it should be identical to setup.h from the build directory checked
above and because lmi ("your program") doesn't have "compatible with 3.0"
in its build configuration string.

 If everything is as expected so far, the explanation of the problem must
be that the binary is finding a wrong wxWidgets DLL. You could use Wine DLL
loading debugging to check which one is being loaded. I don't actually know
where are the different DLLs supposed to be located now, i.e. whether
you've already implemented the proposed directory structure or not yet?
Could it be that the just built DLL is in some arch-dependent directory
while there is still an old version in arch-independent /opt/lmi/local/bin
which is in your PATH? The more I think about it, the more I believe that
this must be it, i.e. lmi must be loading some old DLL, built before you
added --disable-compat30, instead of the new one. Could you please check if
this is the case?

 Thanks in advance,
VZ