[DebianGIS] Re: thuban strict wxPython version check?

[Bernhard Reiter]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20060629/060961df/attachment.bin