I've seen this error described in many messages, but none of the
answers solved my problem.
Trying to run the demo, I get this error:
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.4,compatible with 2.6),
and wxPython used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6).
/tmp/mc-root/mcextgBQCuS: line 2: 3880 Aborted
I'm guessing 'the library' to be wxWidgets? I've recompiled both
wxWidgets and wxPython any number of times, with the same ./configure
arguments, both without
24. compatibility, and I still come back to the same error message.
I've seen this error described in many messages, but none of the
answers solved my problem.
Trying to run the demo, I get this error:
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.4,compatible with 2.6),
and wxPython used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6).
/tmp/mc-root/mcextgBQCuS: line 2: 3880 Aborted
I'm guessing 'the library' to be wxWidgets?
Yes.
I've recompiled both
wxWidgets and wxPython any number of times, with the same ./configure
arguments, both without
24. compatibility, and I still come back to the same error message.
Where does the 2.4 compatibility come from?
Usually mismatches like this happen because wxPython's build is using a different wx than the one you just built. Make sure that the wx-config that setup.py is finding and using is the same one you built and installed for the wxWidgets part of the build. If it isn't then you can force it by putting that install dir first in the PATH or passing WX_CONFIG=/full/path/to/win-config on the setup.py command-line.
Another possibility is that it is finding a different version of wxWidgets at runtime and dynamically linking to that set of shared libraries instead of the set it should be using. You can check this by running ldd (on *nix) or otool -L (mac) on one of the wxPython extension modules to see which libs it is using.
If you are already using the correct wx-config then you should be able to turn off 2.4 compatibility on your next build using --disable-compat24.
If you are already using the correct wx-config then you should be able
to turn off 2.4 compatibility on your next build using --disable-compat24.
Thanks Robin!
As it happens, it seems to have been (at least partly) the Midnight
Commander's fault. Of course I should have paid more attention, but at
times MC doesn't really change directories, even though it does
indicate so. I looked into the config.log and noticed that the option
list didn't coincide with the one I entered (--enable-compat24 was
still there). So, once again, I compiled wxWidgets, without the
option, and behold, no more library mismatches. (BTW, --disable-
compat24, as you suggested, doesn't appear in the ./configure --help
list)
With most programs I tried (eg. the demo.py program), I get segfaults.
In the demo, the splash screen appears and then segfaults.
So I thought I had to recompile wxPython again (as it depends on
wxWidgets), and the library incompatibity re-appeared. Stranger still,
the config.log of _wxPython_ says:
"It was created by wxWidgets configure 2.8.10, which was..."
So I thought I had to recompile wxPython again (as it depends on
wxWidgets), and the library incompatibity re-appeared. Stranger still,
the config.log of _wxPython_ says:
I'm confused. wxPython doesn't have its own configure script. Do you mean the wxWidgets that is included in the wxPython tarball? If so does that mean that you are building wxWidgets twice? If so are they the same version and built with the same options?
"It was created by wxWidgets configure 2.8.10, which was..."
(Still get segfaults)
If you get a core file you can load it in gdb and do a backtrace to find out where the crash happened. That may give a clue what the problem is.