I installed wx from source on linux and I have a lib folder full of libwx_gtk2d_*.so files, but when I try to run something I get “ImportError: libwx_gtk2u_richtext-2.8.so.0: cannot open shared object file: No such file or directory”. I don’t have ‘libwx_gtk2u_richtext-2.8.so.0’ in my lib folder, but a ‘libwx_gtk2d_richtext-2.8.so.0’ (note the ‘d’). What am I doing wrong?
What’s the difference between the “u” and the “d”, I’d hazard a guess that the u is a unicode build but I’m not sure - I’m pretty certain I built it with a unicode flag (–enable-unicode)
I installed wx from source on linux and I have a lib folder full of
libwx_gtk2d_*.so files, but when I try to run something I get
"ImportError: libwx_gtk2u_richtext-2.8.so.0: cannot open shared object
file: No such file or directory". I don't have
'libwx_gtk2u_richtext-2.8.so.0' in my lib folder, but a
'libwx_gtk2d_richtext-2.8.so.0' (note the 'd'). What am I doing wrong?
What's the difference between the "u" and the "d", I'd hazard a guess
that the u is a unicode build but I'm not sure - I'm pretty certain I
built it with a unicode flag (--enable-unicode)
Yes, "u" is unicode and "d" is debug. A "ud" build is possible too.
What configure options did you use? Did the wxPython part of the build use the wx-config script created by the wxWidgets build or some other one that may have already been on the system?
What’s the difference between the “u” and the “d”, I’d hazard a guess
that the u is a unicode build but I’m not sure - I’m pretty certain I
built it with a unicode flag (–enable-unicode)
Yes, “u” is unicode and “d” is debug. A “ud” build is possible too.
What configure options did you use? Did the wxPython part of the build use the wx-config script created by the wxWidgets build or some other one that may have already been on the system?
I think that was my problem, I have installed wxWidgets and wxPython quite a few times now and I think I forgot to set PATH and LD_LIBRARY_PATH, so it had loaded the wrong config. I cleared the build folder and went through a bit more carefully and it’s working great now
Also out of interest, what is the difference between debug / non-debug, unicode / non-unicode builds. I know I’ve built it without unicode support before and I’m sure I could display unicode in the app.
Also out of interest, what is the difference between debug / non-debug,
unicode / non-unicode builds. I know I've built it without unicode
support before and I'm sure I could display unicode in the app.
In 2.8 and prior the unicode option determines whether the contents of the wxString class are unicode values or character values, usually encoded with the system default encoding. So it doesn't make as much difference to whether it is possible to display unicode characters or not (the encodings can manage that) but it does determine how the character data is managed and manipulated within wx. Also, with a unicode build is is much easier to write programs that can deal with any encoding or multiple languages at once. wxPython will try to hide the differences between the two somewhat but there are some limitations there too.
In 2.9 there is just one official build and although some things are done a little differently internally you could consider it to be the same as the unicode builds in prior releases.
In 2.8 a debug build not only included the debug symbols needed to trace through the C++ code in a debugger, but also enabled some diagnostic code that checks things at runtime to help ensure things like valid parameters, avoiding unexpected situations, etc. In wxPython these are turned in to PyAssertionError exceptions to help you correct the problems. If wxWidgets was built without the debug flag then those assertions will not be checked and mistakes or other problems will be more likely to result in a crash.
In 2.9 those assertions are turned on by default in all build types so that makes things much better for us.
Also out of interest, what is the difference between debug / non-debug,
unicode / non-unicode builds. I know I’ve built it without unicode
support before and I’m sure I could display unicode in the app.
In 2.8 and prior the unicode option determines whether the contents of the wxString class are unicode values or character values, usually encoded with the system default encoding. So it doesn’t make as much difference to whether it is possible to display unicode characters or not (the encodings can manage that) but it does determine how the character data is managed and manipulated within wx. Also, with a unicode build is is much easier to write programs that can deal with any encoding or multiple languages at once. wxPython will try to hide the differences between the two somewhat but there are some limitations there too.
In 2.9 there is just one official build and although some things are done a little differently internally you could consider it to be the same as the unicode builds in prior releases.
In 2.8 a debug build not only included the debug symbols needed to trace through the C++ code in a debugger, but also enabled some diagnostic code that checks things at runtime to help ensure things like valid parameters, avoiding unexpected situations, etc. In wxPython these are turned in to PyAssertionError exceptions to help you correct the problems. If wxWidgets was built without the debug flag then those assertions will not be checked and mistakes or other problems will be more likely to result in a crash.
In 2.9 those assertions are turned on by default in all build types so that makes things much better for us.
Awesome, thanks for the explanation! I have now got a ‘ud’ build
