> Python 2.6, gtk
> so here is my compile cmd line.
> ../configure --prefix=/home/franz/src/wxWidgets/mydest -with-gtk -with-gnomeprint --with-opengl --enable-unicode --enable-debug --enable-debug_gdb --enable-geometry --enable-graphics_ctx --enable-sound --with-sdl --enable-display --disable-debugreport --enable-media> UNICODE=1 python setup.py build_ext --inplace --debug
> ~/src/wxPython/demo$ python
> Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import wx
> Traceback (most recent call last):
> File "<stdin>", line 1, in<module>
> File "/home/franz/src/wxPython/wx/__init__.py", line 45, in<module>
> from wx._core import *
> File "/home/franz/src/wxPython/wx/_core.py", line 4, in<module>
> import _core_
> ImportError: /home/franz/src/wxPython/wx/_core_.so: undefined symbol: PyUnicodeUCS2_FromEncodedObject> Is the culprit in wxwidgets compilation or something in wxpython build
> process?I'm going to try to answer all the questions from this thread in just
one message, so please bear with me as I try to copy and paste chunks of
messages so it will all make sense.
Ok
> UNICODE=1 python setup.py build_ext --inplace --debug
* The UNICODE=1 should be on setup.py's part of the command line, not at
the beginning (which just sets it in the environment.)
Aha, so python setup.py build_ext --inplace --debug --unicode?
> ImportError: /home/franz/src/wxPython/wx/_core_.so: undefined symbol: PyUnicodeUCS2_FromEncodedObject
* PyUnicodeUCS2_FromEncodedObject is a Python function. Python has 2
different modes in which its unicode support can be built. One uses UCS2
by default and one uses UCS4 by default, and there are some macros for
the API functions that switch between the two sets based on the
compilation mode.
Aha, complicated.
So in this case something is causing the compilation
of wxPython to think that the Python being used was built in UCS2 mode,
but it is not. This could be the UNICODE=1 issue in the first bullet
point above, or it could be that the Python headers being used for
wxPython's compilation are not the same as those used by the Python that
is being used later when you test import wx.
That could be the problem. (I'm not sure anymore) but I think have
installed python headers some times after the python installation.
* --enable-unicode=ucs4 is a Python configure flag, not wxWidgets.
Thats the reason
* Yes, there is a new set of wxPython build instructions for the 2.9
version of the source. Almost everything is handled by a single script
so the BUILD doc has been shrunk down to one smallish page of text.
This is not the BUILD doc on the website because 2.8 is still the
officially released version. If you want to experiment with unreleased
versions I encourage you to join the wxPython-dev mail list.> ImportError: wx/_core_.so: undefined symbol: _ZN5wxApp10InitializeERiPPw
* This usually means that there is a problem with the wxWidgets build,
or that there is some incompatibility with the build flags between
wxWidgets or wxPython.
I think, wxPython wanted to access wxwidgets ansi build.
> wxWidgets and wxpython from trunk
* If you had been on the wxPython-dev list you would have seen my
announcement that the current wxPython trunk is to be used with the
2.9.1 tagged version of wxWidgets, not the wx trunk.
So I can try a long time, when I choose the wrong branch. 
To make things
like this easier in the future I've made a Mercurial repository
available that will essentially be a snapshot of my local workspace. So
basically in situations like now when I'm not working from the wxWidgets
trunk, this repository will automatically reflect that change with no
extra effort needed on your part. I'll send a message to wxPython-dev
with the details.
But why is not the wxwidgets trunk used? I would be more easy to
choose this.
···
On Aug 23, 5:31 am, Robin Dunn <ro...@alldunn.com> wrote:
On 8/21/10 5:28 AM, FranzSt wrote:
--
Robin Dunn
Software Craftsmanhttp://wxPython.org