Skip Montanaro wrote:

Skip> I poked around for "__ti7wxEvent". All I found were a couple undefined Skip> references: Skip> ./wxPython/build/temp.linux-i686-2.3/helpers.o Skip> U __ti7wxEvent Skip> ./wxPython/build/temp.linux-i686-2.3/dynamicsash.o Skip> U __ti7wxEvent

Robin> I've just tried exactly what you did above on my Mandrake 8.2 Robin> system with Python 2.2 and it works fine.

What file defines wxEvent? You must surely have a .o file which defines it as an exportable symbol.

It should be in wxGTK in src/common/event.cpp (build/event.o).

Robin> One possibility -- since the wxPython build gets its compiler Robin> flags and etc. from Python's build via distutils -- is that there Robin> is some flag conflicting with wxGTK's build that has changed with Robin> Python 2.3. I'd be interested in seeing a copy of a compile Robin> commandline for one of the sources from the wxGTK build and Robin> another one from the wxPython build.

An example from (wxPython's internal) wxGTK with the no_rtti and no_exceptions flags set:

[...] These look okay.

Robin> Another possibility is that it may be fixed simply by disabling Robin> rtti and/or exceptions in the wxGTK build. You can try adding Robin> the following flags and then rebuilding all of wxGTK and Robin> wxPython:

Robin> --enable-no_rtti Robin> --enable-no_exceptions

Just tried that. Running wxPython/demo/demo.py now yields:

Traceback (most recent call last): File "demo.py", line 3, in ? import Main File "Main.py", line 15, in ? from wxPython.wx import * File "/usr/local/lib/python2.3/site-packages/wxPython/__init__.py", line 20, in ? import wxc ImportError: /usr/local/lib/python2.3/site-packages/wxPython/wxc.so: undefined symbol: Eof__C13wxInputStream

which c++filt reports as

wxInputStream::Eof(void) const

The original __ti7wxEvent symbol is no longer to be found anywhere (defined or referenced).

Right, it shouldn't be since you built without RTTI.

Eof__C13wxInputStream is referenced from ./wxPython/build/temp.linux-i686-2.3/helpers.o.

I don't see anyway that a whole method could get lost...

Ah, wait a minute. I see a likely candidate for the screwup:

% type c++ c++ is /usr/local/bin/c++ % c++ --version 3.0.4 % type gcc gcc is /usr/bin/gcc % gcc --version 2.96

Does mix-n-match across GCC versions strike you as a plausible reason for the errors?

...except for this. It's likely that the C++ symbol names are getting mangled differently by the different compiler versions and the one symbol reported by the import exception is just the first one found. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!