On Fri, Aug 30, 2013 at 04:43:06AM +0100, Wookey wrote: > +++ Wookey [2013-08-29 05:01 +0100]: > > When doing the build the samples processing gets as far as the > > 'survex' folder and things go wrong: > > > > > > therion 5.3.11 > > initialization file: /etc/therion.ini > > reading ... done > > configuration file: thconfig.1 > > reading ... done > > reading source files ... done > > preprocessing database ... > > therion: error -- file import -- cave1.th [11] -- unable to open file > > > > cave1.th definitely exists. why would 'source cave1.th' fail? > > > source foo.th has just worked fine in q-marks and pocket-topo and > > morphing/sample1 etc. I am perplexed. > > aha. the issue is not that cave1.th is unable to be openned. It's that > line 11 of cave1.th is: > import cave.3d -surveys use > and _that_ is what's failing. > > There is a cave.3d in the directory with sensible permissions. I > suspect the issue is a new version of survex, so that file is in > version 8 format. > > I suspect something in thimport.cxx (shouldn't therion be using the > survex img.c/img.h files rather than implementing it's own parser?) > Ah. I see it has a copy of img.h, but it's it's own copy in 'extern', > not the actual copy from survex (I guess as survex doesn't actually > provide a survex-dev package with these headers in, therion can't avoid > having an internal copy).
It's intended that you copy those two files to use them. > It seems that line 4 of a v8 file has a date like: > @1377747129 > whearas v6 and v7 had: > Sun,2011.02.27 02:37:02 GMT > (confirmed by checing the 3dformat.htm and 3dformat-old.htm files in > the survex docs) Dates are now stored in a format that's sanely machine readable. > Not sure if that's actually what was breaking. A version the img code which pre-dates v8 of the format can't possibly successfully read it, and will return an error. You should be able to tell this has happened by looking at what img_error() returns (in this case it should be IMG_TOO_NEW). The error given by therion here would be less confusing if it at least reported the filename that img failed to open, and ideally if it also reported the reason as given by img_error(). > Updating to the current > img.* caused: > extern/img.o: In function img_write_item': > img.c:(.text+0x3f38): undefined reference to max' > which needed this putting back to fix: > /* In C++ code, #include<algorithm> and use std::max and std::min > instead. */ > #ifndef __cplusplus > /* Return max/min of two numbers. */ > /* May be defined already (e.g. by Borland C in stdlib.h) */ > /* NB Bad news if X or Y has side-effects... */ > # ifndef max > # define max(X, Y) ((X) > (Y) ? (X) : (Y)) > # endif > # ifndef min > # define min(X, Y) ((X) < (Y) ? (X) : (Y)) > # endif > #endif Oops, I'll restore that in the next Survex release (coming soon). > That lets it build, but now processing samples/survex/thconfig.1 > causes a segfault: > ../../therion thconfig.1 > therion 5.3.11 > cavern - Survex 1.2.7 > initialization file: /etc/therion.ini > reading ... done > configuration file: thconfig.1 > reading ... done > reading source files ... done > preprocessing database ... Segmentation fault > > Which I guess isn't very surprising. > > So I could go back to survex 1.2.6 and build therion. That would > presumably build OK, but I supsect I'd hit problems with and v8 .3d > files in data? You can tell cavern to output older 3d versions with --3d-version=7 though older versions may not support newer features fully. > Can someone who groks C++ take a look at this and see what's needed to > make it work with survex 1.2.7, as that's out now. We'll need to fix > it at some point. If you run the command under gdb, it should show where the segfault is happening: gdb --args ../../therion thconfig.1 And then in gdb "run" and once it fails "bt full" should give a backtrace with local variables shown. > My curent sources are here if someone wants to start from there: > http://wookware.org/software/therion/therion-5.3.11-wook.tar.gz > > BTW building therion now gives an awful lot of: > thdb1d.h: In constructor ???thdb1ds::thdb1ds(const char*, thsurvey*)???: > thdb1d.h:176:19: warning: passing NULL to non-pointer argument 1 of > ???std::list<_Tp, _Alloc>::list(std::list<_Tp, _Alloc>::size_type, const > value_type&, const allocator_type&) [with _Tp = thdata*; _Alloc = > std::allocator<thdata*>; std::list<_Tp, _Alloc>::size_type = long > unsigned int; std::list<_Tp, _Alloc>::value_type = thdata*; > std::list<_Tp, _Alloc>::allocator_type = std::allocator<thdata*>]??? > [-Wconversion-null] > whinges. The "data(NULL)" on line 172 of thdb1d.h should just be "data()" (or removed entirely - a std::list will be default initialised implicitly anyway). Currently the NULL presumably is getting converted to 0 (and that's giving the warning) so it probably is currently creating a list of initial size 0 anyway. Cheers, Olly
