can't get a working build

William_Kyngesburye · March 11, 2009, 2:05am

I'm trying to compile a slim wxpython to embed in an application. I configured wx with:

--enable-debug_flag --disable-debug_info

(the python exceptions thing sounded useful, I just don't want the debug symbols bloating the libraries)

And the wxpython setup.py picks that up from wx-config. I verified that both are compiling with -D__WXDEBUG__.

When running the wx-based application (pure python at this point), I get:

Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6),
and wxPython used 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers).

The only difference I see is the 2.6 comptibility. I didn't see a 2.6 compatibility option for the wxpython setup.py.

If I build wx without 2.6 compatibility, wxpython fails to compile:

gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE -arch i386 -arch ppc -pipe -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_IODBC_ -D__WXDEBUG__ -D__WXMAC__ -Iinclude -Isrc -I/Users/Shared/unix/wxpython-leo/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/unix/wxpython-leo/include/wx-2.8 -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c src/mac/_core_wrap.cpp -o build.unicode/temp.macosx-10.5-i386-2.5/src/mac/_core_wrap.o -O3
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++
src/mac/_core_wrap.cpp: In function ‘bool wxSizer_Remove(wxSizer*, PyObject*)’:
src/mac/_core_wrap.cpp:4652: error: invalid conversion from ‘wxWindow*’ to ‘int’src/mac/_core_wrap.cpp: In function ‘bool wxSizer_Remove(wxSizer*, PyObject*)’:
src/mac/_core_wrap.cpp:4652: error: invalid conversion from ‘wxWindow*’ to ‘int’

src/mac/_core_wrap.cpp:4652: error: initializing argument 1 of ‘virtual bool wxSizer::Remove(int)’
src/mac/_core_wrap.cpp:4652: error: initializing argument 1 of ‘virtual bool wxSizer::Remove(int)’
src/mac/_core_wrap.cpp: In function ‘PyObject* _wrap_GetAccelFromString(PyObject*, PyObject*, PyObject*)’:
src/mac/_core_wrap.cpp:33817: error: ‘wxGetAccelFromString’ was not declared in this scope
src/mac/_core_wrap.cpp: In function ‘PyObject* _wrap_GetAccelFromString(PyObject*, PyObject*, PyObject*)’:
src/mac/_core_wrap.cpp:33817: error: ‘wxGetAccelFromString’ was not declared in this scope
src/mac/_core_wrap.cpp: In function ‘void init_core_()’:
src/mac/_core_wrap.cpp:63781: error: ‘wxPROCESS_ENTER’ was not declared in this scope
src/mac/_core_wrap.cpp:63782: error: ‘wxPASSWORD’ was not declared in this scope
src/mac/_core_wrap.cpp:64083: error: ‘WXK_PRIOR’ was not declared in this scope
src/mac/_core_wrap.cpp:64084: error: ‘WXK_NEXT’ was not declared in this scope
src/mac/_core_wrap.cpp:64153: error: ‘WXK_NUMPAD_PRIOR’ was not declared in this scope
src/mac/_core_wrap.cpp:64155: error: ‘WXK_NUMPAD_NEXT’ was not declared in this scope
src/mac/_core_wrap.cpp: In function ‘void init_core_()’:
src/mac/_core_wrap.cpp:63781: error: ‘wxPROCESS_ENTER’ was not declared in this scope
src/mac/_core_wrap.cpp:63782: error: ‘wxPASSWORD’ was not declared in this scope
src/mac/_core_wrap.cpp:64083: error: ‘WXK_PRIOR’ was not declared in this scope
src/mac/_core_wrap.cpp:64084: error: ‘WXK_NEXT’ was not declared in this scope
src/mac/_core_wrap.cpp:64153: error: ‘WXK_NUMPAD_PRIOR’ was not declared in this scope
src/mac/_core_wrap.cpp:64155: error: ‘WXK_NUMPAD_NEXT’ was not declared in this scope

So it seems like 2.6 compatibility is a requirement for wxpython, though it's not mentioned in the documentation.

Finally, building wx and wxpython without any debug flags at all, no complaints, the app runs.

···

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

Robin · March 11, 2009, 10:01pm

William Kyngesburye wrote:

I'm trying to compile a slim wxpython to embed in an application. I configured wx with:

--enable-debug_flag --disable-debug_info

(the python exceptions thing sounded useful, I just don't want the debug symbols bloating the libraries)

And the wxpython setup.py picks that up from wx-config. I verified that both are compiling with -D__WXDEBUG__.

When running the wx-based application (pure python at this point), I get:

Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6),
and wxPython used 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers).

The only difference I see is the 2.6 comptibility. I didn't see a 2.6 compatibility option for the wxpython setup.py.

There isn't one. wxPython should just use what wxWidgets was built with.

The problem you are having is most likely that there is more than one set of wxWidgets dylibs on your system and the wrong one is being picked up either by your app or by wxPython. Use otool -L to see the dylibs that are being loaded by your app and compare to the otool -L output from wxPython's _core_.so.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

William_Kyngesburye · March 11, 2009, 10:32pm

I thought of that already. The crash report that this fatal error causes says that the correct copies of the wx libraries are loaded (shown in the binary images section).

I do have wxpython installed from the 'official' installer, but since it is isolated in its own versioned folder, it shouldn't be able to find that.

There are the system wx libraries - same library version, though wxpython is older. The application I'm bundling wxpython into starts initially in the shell and sets DYLD_LIBRARY_PATH, which should force the linker to try the bundle path first, but maybe there is some confusion, and the crash report is misleading. I'll try changing the install_names in the wxpython binary extensions to a relative path (@loader_path) and see if that helps.

···

On Mar 11, 2009, at 5:01 PM, Robin Dunn wrote:

The problem you are having is most likely that there is more than one set of wxWidgets dylibs on your system and the wrong one is being picked up either by your app or by wxPython. Use otool -L to see the dylibs that are being loaded by your app and compare to the otool -L output from wxPython's _core_.so.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

William_Kyngesburye · March 12, 2009, 1:31am

Well, before I got a chance to try the @loader_path, I did a complete rebuild (yet again) of wxwidgets and wxpython with debug-flag, and rebundled the app. Now it works. Go figure.

···

On Mar 11, 2009, at 5:32 PM, William Kyngesburye wrote:

On Mar 11, 2009, at 5:01 PM, Robin Dunn wrote:

The problem you are having is most likely that there is more than one set of wxWidgets dylibs on your system and the wrong one is being picked up either by your app or by wxPython. Use otool -L to see the dylibs that are being loaded by your app and compare to the otool -L output from wxPython's _core_.so.

I thought of that already. The crash report that this fatal error causes says that the correct copies of the wx libraries are loaded (shown in the binary images section).

I do have wxpython installed from the 'official' installer, but since it is isolated in its own versioned folder, it shouldn't be able to find that.

There are the system wx libraries - same library version, though wxpython is older. The application I'm bundling wxpython into starts initially in the shell and sets DYLD_LIBRARY_PATH, which should force the linker to try the bundle path first, but maybe there is some confusion, and the crash report is misleading. I'll try changing the install_names in the wxpython binary extensions to a relative path (@loader_path) and see if that helps.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect