On Thu, Jun 08, 2006 at 05:22:33PM +0200, Bernhard Herzog wrote: > Paul Wise <[EMAIL PROTECTED]> writes: > > > I'm wondering what the following check from Thuban/version.py is for? Is > > the wxWidgets ABI really so fragile that wxProj breaks on new minor > > 2.6.X versions or new 2.4.X versions? Surely using the soname to do > > version checks with the normal shared library support is enough? > > The symptom people often see when using Thuban with a different > wxWidgets version -- even when it's only a different minor version -- is > that it segfaults as soon as it tries to actually render a map on the > screen. In the past there were enough problem reports from users about > this for us to put in the version check so that users would at least get > a meaningful error message instead of just a segfault. > > The reason for the crashes is that wxproj accesses wxPython objects at > the C++-level to extract the corresponding wxWidgets object so that it > can call wxWidgets methods directly. That way, Thuban can render data > read from e.g. a shapefile without having to funnel the data through > Python which improves rendering speed considerably. > > Unfortunately, this means that the wxWidgets object used by wxproj has > been created by the wxWidgets library wxPython is linked with and that > may be different from the one wxproj is linked with. The libraries may > differ in the layout of the classes and/or virtual tables depending on > the version and perhaps compile time options. > > Bernhard >
I'm not a python addicted, but I suspect this issue should be managed at python-wxgtk2.4 level. Incompatibilities in ABIs should be managed using different source packages to avoid conflicts. I'm CC to d-python list for analysis... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
