On Fri, Jun 09, 2006 at 09:10:01PM +0200, Francesco Paolo Lovergine wrote: > On Thu, Jun 08, 2006 at 05:22:33PM +0200, Bernhard Herzog wrote: > > Paul Wise <pabs3@bonedaddy.net> 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. > I'm not a python addicted, but I suspect this issue should be managed > at python-wxgtk2.4 level. Note that wxproj is a package that currently comes with Thuban. Obviously is cures a weakness of wx and wxPython, but the fix might be a major effort, this is why wxproj is helpful. > Incompatibilities in ABIs should be managed > using different source packages to avoid conflicts. I think we are grateful for hint on how to improve the current situation without major hassle. One idea to be evalutated could to be make a wxproj package seperate from Thuban, which would limit the dependecies I assume. > I'm CC to d-python > list for analysis... If there are hints, please also give them to thuban-devel. Thanks, Bernhard
Attachment:
signature.asc
Description: Digital signature