Re: [lmi] wx mismatch between versions

[Greg Chicares]

On 2017-05-30 23:55, Vadim Zeitlin wrote:
> 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).

[...and rebuilding didn't help...]

>  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.

It's all for the best, because it exposed a problem I had created.

> 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.

That would just turn a manifest defect into a latent defect, so...

>  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

I'm not maintaining a current gtk build yet, but here's the msw analog:

/opt/lmi/src/lmi[0]$fgrep WXWIN_COMPATIBILITY_3_0 
../../wx-scratch/wxWidgets-3.1.0-p1/gcc-491-89775012799fe5c9bd8ea61e5fa43da7/lib/wx/include/i686-w64-mingw32-msw-unicode-3.1/wx/setup.h
#define WXWIN_COMPATIBILITY_3_0 0

It's zero, as expected:

> 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

/opt/lmi/src/lmi[0]$fgrep WXWIN_COMPATIBILITY_3_0 
../../local/lib/wx/include/i686-w64-mingw32-msw-unicode-3.1/wx/setup.h
#define WXWIN_COMPATIBILITY_3_0 0

This one is also zero.

> (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.

So far so good.

>  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.

/opt/lmi/bin[0]$WINEDEBUG='+loaddll' wine ./lmi_wx_shared --ash_nazg 
--data_path=/opt/lmi/data
...
trace:loaddll:load_native_dll Loaded 
L"Z:\\opt\\lmi\\bin\\wxmsw311u_gcc_gcc-491-89775012799fe5c9bd8ea61e5fa43da7.dll"
 at 0x71100000: native
trace:loaddll:load_native_dll Loaded 
L"Z:\\opt\\lmi\\bin\\wxcode_mswu_pdfdoc-3.1.dll" at 0x5010000: native

Here's the problem:

/opt/lmi/src/lmi[0]$ls -l /opt/lmi/ |grep wx-scratch
drwxr-xr-x  3 greg greg     4096 May 30 23:04 wx-scratch
/opt/lmi/src/lmi[0]$ls -l 
/opt/lmi/local/lib/wxmsw311u_gcc_gcc-491-89775012799fe5c9bd8ea61e5fa43da7.dll
-rwxr-xr-x 1 greg greg 19408945 May 30 23:06 
/opt/lmi/local/lib/wxmsw311u_gcc_gcc-491-89775012799fe5c9bd8ea61e5fa43da7.dll
/opt/lmi/src/lmi[0]$ls -l 
/opt/lmi/bin/wxmsw311u_gcc_gcc-491-89775012799fe5c9bd8ea61e5fa43da7.dll
-rwxr-xr-x 1 greg greg 21317038 May 19 21:27 
/opt/lmi/bin/wxmsw311u_gcc_gcc-491-89775012799fe5c9bd8ea61e5fa43da7.dll

I had already looked in /opt/lmi/local/lib/ and observed that the wx
dll there is the one I had just built. But that's not the one traced
by wine, which is in /opt/lmi/bin/ , where it certainly does not
belong. I believe I copied it there as a shortcut that went long.
I've deleted the {wx wxpdfdoc libxml2 lib[e]xslt} dlls there, and
now everything works.

> 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?

Not yet. It's a major change: "/opt/lmi" is hardcoded in many places,
and it needs to be changed to $(exec_prefix)/whatever . I've made notes
on what to change, but building for x86_64 is still only a kludge. This
unfinished work has been competing with a new insurance calculation
that we want to release this month, but I'm trying to get it done in
the next two weeks so that then I can have a nice leisurely root canal.

> 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?

That was essentially the problem. Thanks for going through it with me.