I've been fighting to get loch to work with wxWidgets 3.0.0. The first obstacle is that they now enable __WXDEBUG__ mode by default, so misuses of the API result in warning dialogs popping up. I've attached a patch which fixes that, and updates a couple of places where deprecated methods are used. This doesn't get you a fully working loch though - starting loch and loading a file seems to work OK, *if* loch was compiled with optimisation. Starting loch with a file specified on the command line segfaults in the first call to gluScaleImage() in lxData.cxx, though it works when run under gdb or valgrind, so I guess there is a subtle timing issue (and that this might not happen on all machines). There are also more uses of deprecated methods, most notably using an implicit wxGLContext is now deprecated. I tried to update that one, but things seemed to crash a lot - I suspect the underlying problem noted above needs addressing first. I've been testing on Debian unstable (which has packages of wx 3.0.0). Cheers, Olly
+++ Olly Betts [2013-11-15 14:14 +0000]:
I've been fighting to get loch to work with wxWidgets 3.0.0. The first obstacle is that they now enable __WXDEBUG__ mode by default, so misuses of the API result in warning dialogs popping up.
I've attached a patch which fixes that, and updates a couple of places where deprecated methods are used.
This doesn't get you a fully working loch though - starting loch and loading a file seems to work OK, *if* loch was compiled with optimisation. Starting loch with a file specified on the command line segfaults in the first call to gluScaleImage() in lxData.cxx, though it works when run under gdb or valgrind, so I guess there is a subtle timing issue (and that this might not happen on all machines).
There are also more uses of deprecated methods, most notably using an implicit wxGLContext is now deprecated. I tried to update that one, but things seemed to crash a lot - I suspect the underlying problem noted above needs addressing first.
This is now a release-critical issue in Debian, and therion is going to get thrown out if we can't fix it. therion 5.3.14-1 is marked for autoremoval from testing on 2014-06-27 It is affected by these RC bugs: 749687: therion: Please update to use wxwidgets3.0 Stacho - I think you understand loch - can you find some time to look into this and see what we need to do to make it work properly (does wx3 work on Windows?, do you have access to a Debian machine?) (And looking at VTK6 would be good too, although I'm not actually completely stuck there yet). Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
Unfortunatelly, I do not understand what exactly is the problem with wx 3.0. I have installed debian jessie/sid on my virtual linux box and all I needed to do to get therion 5.3.15 working was related to VTK6. I needed to change lxData.cxx and link all existing vtk libraries in the system this dirty way: VTKLIB = $(addprefix -l,$(subst xxxlib,,$(addprefix xxx,$(notdir $(basename $(shell ls /usr/lib/x86_64-linux-gnu/libvtk*-6.1.so)))))) VTKLIBS = $(VTKLIB) -lfreetype -lpng -ljpeg No need to change anything with wx3.0. When I run loch - it prints a lot of assertions, but it runs without any problem, if I click to ignore them. I have not yet tested Olly's patches, I have done this two weeks ago or so. Even running loch with filename as argument works fine. I have not tried on a box with 3D hardware acceleration, may be there timing issue will rise. But is this related with wx3.0? As far as I know, there were problems with intel 3D cards on Linux box from the beginning. S. On 13 June 2014 11:18, Wookey <wookey@wookware.org> wrote:
+++ Olly Betts [2013-11-15 14:14 +0000]:
I've been fighting to get loch to work with wxWidgets 3.0.0. The first obstacle is that they now enable __WXDEBUG__ mode by default, so misuses of the API result in warning dialogs popping up.
I've attached a patch which fixes that, and updates a couple of places where deprecated methods are used.
This doesn't get you a fully working loch though - starting loch and loading a file seems to work OK, *if* loch was compiled with optimisation. Starting loch with a file specified on the command line segfaults in the first call to gluScaleImage() in lxData.cxx, though it works when run under gdb or valgrind, so I guess there is a subtle timing issue (and that this might not happen on all machines).
There are also more uses of deprecated methods, most notably using an implicit wxGLContext is now deprecated. I tried to update that one, but things seemed to crash a lot - I suspect the underlying problem noted above needs addressing first.
This is now a release-critical issue in Debian, and therion is going to get thrown out if we can't fix it.
therion 5.3.14-1 is marked for autoremoval from testing on 2014-06-27 It is affected by these RC bugs: 749687: therion: Please update to use wxwidgets3.0
Stacho - I think you understand loch - can you find some time to look into this and see what we need to do to make it work properly (does wx3 work on Windows?, do you have access to a Debian machine?)
(And looking at VTK6 would be good too, although I'm not actually completely stuck there yet).
Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
+++ Stacho Mudrak [2014-06-14 12:16 +0200]:
Unfortunatelly, I do not understand what exactly is the problem with wx 3.0. I have installed debian jessie/sid on my virtual linux box and all I needed to do to get therion 5.3.15 working was related to VTK6. I needed to change lxData.cxx and link all existing vtk libraries in the system this dirty way: VTKLIB = $(addprefix -l,$(subst xxxlib,,$(addprefix xxx,$(notdir $(basename $(shell ls /usr/lib/x86_64-linux-gnu/libvtk*-[1]6.1.so)))))) VTKLIBS = $(VTKLIB) -lfreetype -lpng -ljpeg
OK. I have a more specific library list, from using the tool they provide to analyse your code for library requirements. -lvtkCommonCore -lvtkCommonDataModel -lvtkFiltersCore -lvtkFiltersHybrid -lvtkIOLegacy -lvtkjpeg -lvtkpng I don't think that adding all 363 vtk libraries to the link link is the right way to go ! Can you send me your vtk6 lxData.cxx patch? I've made one but don't really know what I'm doing so am not sure if it's right.
No need to change anything with wx3.0. When I run loch - it prints a lot of assertions, but it runs without any problem, if I click to ignore them. I have not yet tested Olly's patches, I have done this two weeks ago or so. Even running loch with filename as argument works fine.
OK. Interesting. Thanks for doing that.
I have not tried on a box with 3D hardware acceleration, may be there timing issue will rise. But is this related with wx3.0?
I guess if it works on some machines then remaining issues may well be hardware/driver specific. Although it's odd that wx2.8 does nnot produce issues on the same hardware. I'll test on my machines and see what I get.
As far as I know, there were problems with intel 3D cards on Linux box from the beginning.
There was for a time but that went away a couple of years ago. And yes that apeared to be a problem at the wx/opengl drivers level. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
On Sat, Jun 14, 2014 at 12:16:31PM +0200, Stacho Mudrak wrote:
Unfortunatelly, I do not understand what exactly is the problem with wx 3.0.
I have installed debian jessie/sid on my virtual linux box and all I needed to do to get therion 5.3.15 working was related to VTK6.
I needed to change lxData.cxx and link all existing vtk libraries in the system this dirty way:
VTKLIB = $(addprefix -l,$(subst xxxlib,,$(addprefix xxx,$(notdir $(basename $(shell ls /usr/lib/x86_64-linux-gnu/libvtk*-6.1.so)))))) VTKLIBS = $(VTKLIB) -lfreetype -lpng -ljpeg
No need to change anything with wx3.0.
When I run loch - it prints a lot of assertions, but it runs without any problem, if I click to ignore them.
My patch from the message at start of this thread should fix those assertions. Another option is to build with -DNDEBUG - this will disable these assertion messages, and wx3.0 will then handle these cases quietly, just like it does in a default build of wx2.8. However, these assertions are due to incorrect uses of the wx API, so it's better to try to actually deal with them really. The assertion dialogs appearing will of course change the timing though, so you may find that without them you see the problems I do.
I have not yet tested Olly's patches, I have done this two weeks ago or so.
This isn't one of the patches I sent recently - it was sent to this list in November last year: http://thread.gmane.org/gmane.comp.gis.therion/3886 The more recent patches aren't connected to wx3.0 support.
Even running loch with filename as argument works fine. I have not tried on a box with 3D hardware acceleration, may be there timing issue will rise. But is this related with wx3.0? As far as I know, there were problems with intel 3D cards on Linux box from the beginning.
I think I did compare results with the build of loch already in Debian, but I'll recheck. FWIW, I do have intel graphics hardware in the machine I have been testing on, but other 3D stuff seems to work fine. Cheers, Olly
participants (3)
-
Olly Betts -
Stacho Mudrak -
Wookey