Glynn:
Breaking backwards compatibility is allowed in 7.0. We'll probably be
breaking raster compatibility at some point (but in a far more
fundamental way; old rasters won't be recognised at all).
Something this fundamental should have been announced (maybe it was
and I missed it). Also, the error message is misleading.
I will announce it more loudly next time :-)
The error message should be fixed, see other post.
Markus:
My argument is that
enabling backwards compatibility would be about the same effort like
rebuilding topology. I could write a module that converts any existing
sidx file to the new format or builds the spatial index from topo if no
sidx file is found, then writes a new sidx file in the new format. That
would avoid rebuilding the core topology and category index.
Maybe the sidx file should have been renamed?
That would be fool-proof and no problem.
PERMANENT/vector/fields contains:
-rw-r--r-- 1 root root 4117 May 25 2004 cidx
-rw-r--r-- 1 root root 27905 May 25 2004 coor
-rw-r--r-- 1 root root 55 May 25 2004 dbln
-rw-r--r-- 1 root root 278 May 25 2004 head
-rw-r--r-- 1 root root 186 May 25 2004 hist
-rw-r--r-- 1 root root 24538 May 25 2004 sidx
There is no sidx file for vectors in
http://grass.osgeo.org/sampledata/spearfish_grass60data-0.3.tar.gz
IOW: sidx was removed in 6.0 (existing sidx files were silently
ignored), then an entirely different sidx file was added recently, and
the code is confused by the existence of a 5.7 sidx file, right?
Yes. I wasn't aware that 5.7 was writing sidx files. I found the
spearfsh57 sample dataset just now, will use it for more testing in the
future.
Also, this needs to be checked for anything which uses VECT_CFLAGS,
which isn't limited to v.* modules (a few g.* and r.* modules use
vector functions).
I fixed r.drain, v.in.dxf, v.vol.rst. AFAICT all other g.*, r.* and v.*
modules are ok. Please let me know if I missed something.
I don't know which modules need fixing and which don't. I was just
pointing out that e.g. g.{copy,remove,rename,list} use the vector
libraries (but don't use VECT_CFLAGS; is that a bug?)
Yes. Anything that uses vector libraries must use the same LFS-related
flags like the vector libs, otherwise there can be segfaults because the
size of a number of structures, most importantly struct Map_info, is on
32bit systems dependent on the LFS flags.
, r.to.vect,
d.vect, etc use the libraries and VECT_CFLAGS, so it isn't just v.*
modules which need to be checked. It might just be v.* modules which
need to be fixed; I don't know.
OK. I will check all modules including <grass/vector.h> or any of the
headers in include/vect. All vector modules should be fixed by now. Of
the raster modules, only r.drain needed fixing, all other were ok. But I
will check again.
I got carried away (replacing all fseek/ftell occurrences I could find
with G_fseek/G_ftell, adjusting off_t as you showed above) and also made
r3.in|out.v5d LFS-safe, but did not submit. Should I?
Yes;
Will do, testing highly welcome!
ideally, we should use G_{fseek,ftell} everywhere. Ultimately, it
would be better to enable -D_FILE_OFFSET_BITS=64 globally (to ensure
that there aren't any cases where a FILE* is obtained via fopen64()
then passed to code which can't handle it), which means making
everything LFS-aware.
That's beyond my scope because aclocal.m4 and configure.in need
adjustment, and I won't touch these. I guess you are suitably qualified
for the task ;-)
Markus M
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
