I finally got round to uploading the work I did in January to Debian proper. So there is now a current Therion in unstable as well as experimental, and the various long-standing bugs are fixed. The new packages use texlive instead of tetex, as Debian has transitioned to these, and the wiki docs are included in the therion-docs package (that's currently the wiki docs as of about a year ago. I'll update those too shortly). The package now appears in Applications/Science/Geoscience in line with current menu policy (I'll do an update of Survex with this property too soon). You can see current package status here: http://packages.qa.debian.org/t/therion.html and build logs here: http://buildd.debian.org/pkg.cgi?pkg=therion Please try them out if you can and report any problems. I've included the current debian diff below in case Stacho wishes to include any of it upstream (I'm afraid I've trampled all over your nice multiplatform build stuff stacho, but a few bits of the diff are probably worth incorporating upstream). This has raised a few issues worthy of note. 1) 64-bit loch Wolfgang Zillig reported in April that he couldn't get loch to work on his AMD64 box. It doesn't work on mine either. I'll post more details in that thread. 2) gcc warnings The therion code generates hundreds of warnings if you do a build with default gcc4.2.2 like this: thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' I've worked around that for now using -Wno-write-strings but I think the correct fix is to use const in the function prototypes to match the declarations. You can see a log of the full set of whinges here if someone wants to go through them: http://buildd.debian.org/fetch.cgi?pkg=therion;ver=0.5.0-2;arch=ia64;stamp=1... The gcc docs suggest that -Wno-deprecated should also stop these warnings, but that doesn;t seem to work. Not sure if I was just having finger trouble/too much beer over xmas there, but it really didn't seem to stop them all. 3) New sample data I had a bit of trouble building this, so it's not in the current package, but I've worked it out now (paths and dependencies was the issue) and so will integrate it into the docs package on the next upload. It's a nice piece of work. Is this intended to replace the wiki docs eventually? 4) tcl version. Does Therion care if tcl 8.4 or 8.5 is used? I've left it defaulting 8.4 for now, but I guess 8.5 would work and would be preferred? A quick test suggests that it works fine. 5) library linkages: The shared-library analyser points out that we link to all the wxgtk libs but only actually use some of them. This is wrong. dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_xrc-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_qa-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_adv-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_baseu_xml-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_baseu_net-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libvtkImaging.so.5.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libvtkIO.so.5.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libz.so.1 (it uses none of its symbols). I think the reason is that the build uses: $(shell wx-config --libs --gl-libs) to list the wx libs so gets all of them. I haven't fixed this yet as I'm not sure what the best fix is. Should we just list the libs that actually are used, or is there a way to use wx-config to DTRT? 6) No desktop files Therion doesn't appear to have any desktop files so it doesn't appear in the main menus of xfce/gnome/kde. Anyone done any, or care to do some? Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/
On Thu, Jan 03, 2008 at 04:42:27PM +0000, Wookey wrote:
I think the reason is that the build uses: $(shell wx-config --libs --gl-libs) to list the wx libs so gets all of them. I haven't fixed this yet as I'm not sure what the best fix is. Should we just list the libs that actually are used, or is there a way to use wx-config to DTRT?
You can list the libs you want like so (note I've not even looked at what loch might need - this just shows the syntax): wx-config --libs core,base Cheers, Olly
Hmmm, runs on my AMD64 box. I'm also running Gentoo and not Debian, but that shouldn't matter. Philip Schuchardt On Jan 3, 2008, at 11:42 AM, Wookey wrote:
I finally got round to uploading the work I did in January to Debian proper. So there is now a current Therion in unstable as well as experimental, and the various long-standing bugs are fixed.
The new packages use texlive instead of tetex, as Debian has transitioned to these, and the wiki docs are included in the therion-docs package (that's currently the wiki docs as of about a year ago. I'll update those too shortly).
The package now appears in Applications/Science/Geoscience in line with current menu policy (I'll do an update of Survex with this property too soon).
You can see current package status here: http://packages.qa.debian.org/t/therion.html and build logs here: http://buildd.debian.org/pkg.cgi?pkg=therion
Please try them out if you can and report any problems.
I've included the current debian diff below in case Stacho wishes to include any of it upstream (I'm afraid I've trampled all over your nice multiplatform build stuff stacho, but a few bits of the diff are probably worth incorporating upstream).
This has raised a few issues worthy of note.
1) 64-bit loch
Wolfgang Zillig reported in April that he couldn't get loch to work on his AMD64 box. It doesn't work on mine either. I'll post more details in that thread.
2) gcc warnings
The therion code generates hundreds of warnings if you do a build with default gcc4.2.2 like this: thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' thdataleg.h:141: warning: deprecated conversion from string constant to 'char*'
I've worked around that for now using -Wno-write-strings but I think the correct fix is to use const in the function prototypes to match the declarations. You can see a log of the full set of whinges here if someone wants to go through them: http://buildd.debian.org/fetch.cgi?pkg=therion;ver=0.5.0-2;arch=ia64;stamp=1...
The gcc docs suggest that -Wno-deprecated should also stop these warnings, but that doesn;t seem to work. Not sure if I was just having finger trouble/too much beer over xmas there, but it really didn't seem to stop them all.
3) New sample data
I had a bit of trouble building this, so it's not in the current package, but I've worked it out now (paths and dependencies was the issue) and so will integrate it into the docs package on the next upload.
It's a nice piece of work. Is this intended to replace the wiki docs eventually?
4) tcl version.
Does Therion care if tcl 8.4 or 8.5 is used? I've left it defaulting 8.4 for now, but I guess 8.5 would work and would be preferred? A quick test suggests that it works fine.
5) library linkages: The shared-library analyser points out that we link to all the wxgtk libs but only actually use some of them. This is wrong.
dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_xrc-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_qa-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_adv-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_baseu_xml-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_baseu_net-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libvtkImaging.so.5.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libvtkIO.so.5.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libz.so.1 (it uses none of its symbols).
I think the reason is that the build uses: $(shell wx-config --libs --gl-libs) to list the wx libs so gets all of them. I haven't fixed this yet as I'm not sure what the best fix is. Should we just list the libs that actually are used, or is there a way to use wx-config to DTRT?
6) No desktop files
Therion doesn't appear to have any desktop files so it doesn't appear in the main menus of xfce/gnome/kde. Anyone done any, or care to do some?
Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/ <debian.diff>_______________________________________________ Therion mailing list Therion@speleo.sk http://www.speleo.sk/mailman/listinfo/therion
On 2008-01-03 13:13 -0500, Philip Schuchardt wrote:
Hmmm, runs on my AMD64 box. I'm also running Gentoo and not Debian, but that shouldn't matter.
Which version? Plain 0.5.1 tarball? If I do make debian-config; cd loch; make the resulting loch still segfaults on running. Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/
Okay, so I just built the development version, usually the most stable (ironic). I get the same hash table warning issues. Loch does work and doesn't segfault on my machine. Did you rebuild your lox models? There was a binary file bug in lox file that only effects AMD64 arches. Philip Schuchardt On Jan 3, 2008, at 6:16 PM, Wookey wrote:
On 2008-01-03 13:13 -0500, Philip Schuchardt wrote:
Hmmm, runs on my AMD64 box. I'm also running Gentoo and not Debian, but that shouldn't matter.
Which version? Plain 0.5.1 tarball?
If I do make debian-config; cd loch; make the resulting loch still segfaults on running.
Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/ _______________________________________________ Therion mailing list Therion@speleo.sk http://www.speleo.sk/mailman/listinfo/therion
On 2008-01-03 19:21 -0500, Philip Schuchardt wrote: [down with top-posters]
Okay, so I just built the development version, usually the most stable (ironic).
I get the same hash table warning issues.
Loch does work and doesn't segfault on my machine. Did you rebuild your lox models? There was a binary file bug in lox file that only effects AMD64 arches.
I haven't tried loading a model yet. I just ran 'loch'. So that can't be it. Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/
On 2008-01-03 16:42 +0000, Wookey wrote: I forgot 7) Loch warnings: Building loch gives a lot of this: In file included from /usr/include/wx-2.6/wx/gtk/cursor.h:23, from /usr/include/wx-2.6/wx/cursor.h:24, from /usr/include/wx-2.6/wx/event.h:32, from /usr/include/wx-2.6/wx/wx.h:23, from lxWX.h:6, from lxAboutDlg.cxx:1: /usr/include/wx-2.6/wx/image.h: In member function ‘wxImageHistogramBase_wxImplementation_HashTable::Node** wxImageHistogramBase_wxImplementation_HashTable::GetNodePtr(const long unsigned int&) const’: /usr/include/wx-2.6/wx/image.h:123: warning: dereferencing type-punned pointer will break strict-aliasing rules Which is something to do with referencing structure members using pointer types which can not be guaranteed to have the same alignment as the pointer the member was assigned with. All these appear to be in wx headers, so maybe they are not really anything to do with therion, and all I should do is add -fno-strict-aliasing to the build to stop them appearing. But I'd like someone who groks C++ properly to tell me that's not just papering over cracks before doing so. Doing this certainly removes all the noise and shows us that there is one genuine set of warnings: lxRender.cxx: In member function ‘void lxRenderFile::RenderPDFHeader()’: lxRender.cxx:855: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ lxRender.cxx: In member function ‘void lxRenderFile::RenderPDFFooter()’: lxRender.cxx:929: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 5 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 6 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 7 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 8 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 9 has type ‘size_t’ lxRender.cxx:982: warning: format ‘%010u’ expects type ‘unsigned int’, but argument 10 has type ‘size_t’ lxRender.cxx:983: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ Does this just need some casts or should the format be changed? Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/
On Thu, Jan 03, 2008 at 11:14:45PM +0000, Wookey wrote:
All these appear to be in wx headers, so maybe they are not really anything to do with therion, and all I should do is add -fno-strict-aliasing to the build to stop them appearing.
That's probably the simplest fix.
But I'd like someone who groks C++ properly to tell me that's not just papering over cracks before doing so.
ISO C and C++ state in what cases the compiler can assume two pointers to different types don't alias each other. In other words, when a write through one pointer won't affect data read by the other. In recent years, compilers have started to make more aggressive use of the optimisations these rules allow, which causes problems for older code which "works fine", but isn't actually valid C/C++. So GCC helpfully now produces warnings about code which it notices appears to violate these aliasing rules. So it's papering over the cracks in a sense in that the code isn't valid C/C++, but you could think of it as the code being written in a non-standardised dialect of C/C++ in which all pointers are assumed to be able to alias. This may lose some performance - whether it actually makes much difference depends on the nature of the code.
Doing this certainly removes all the noise and shows us that there is one genuine set of warnings: lxRender.cxx: In member function ???void lxRenderFile::RenderPDFHeader()???: lxRender.cxx:855: warning: format ???%u??? expects type ???unsigned int???, but argument 3 has type ???size_t??? lxRender.cxx: In member function ???void lxRenderFile::RenderPDFFooter()???: lxRender.cxx:929: warning: format ???%u??? expects type ???unsigned int???, but argument 3 has type ???size_t??? [...]
Does this just need some casts or should the format be changed?
One or the other - printf format "%u" expects "unsigned int", but is being passed size_t which is 64 bits not 32 on 64 bit Linux. If the parameter could take any value, the format should be fixed. If it will always fit in a 32 bit value, casting to "unsigned int" is fine. Cheers, Olly
participants (3)
-
Olly Betts -
Philip Schuchardt -
Wookey