I see that in r55582 was changed the type of line parameter in
Vect_rewrite_line, Vect_restore_line and Vect_delete_line from int to
off_t. It makes it impossible to use those functions from an
application compiled with a compiler which has different off_t size,
which is the case for QGIS / OSGeo4W (also some Ubuntu builds). It
seems that a single function is used for two different purposes,
change a line in file by offset on level 1 and change a line by line
id on level 2. Unfortunately V2_*_line functions were also changed to
off_t.
Do you know about any workaround?
I can only imagine a dirty hack like (not sure if it would work):
typedef my_off_t <type used by GRASS compiler>
typedef int Vect_delete_line_type(struct Map_info *, my_off_t);
Vect_delete_line_type *Vect_delete_line_pointer = Vect_delete_line;
Vect_delete_line_pointer(map, line);
Can I get from GRASS includes the real type of off_t which was used
when GRASS was compiled?
Can I get from GRASS includes the real type of off_t which was used
when GRASS was compiled?
Not easily. Or reliably. You could use the compiler switches from
Platform.make and include <grass/config.h> in the hope that it's
enough to get the same off_t that GRASS used.
Ultimately, the only place where the actual off_t size is "known" is
in compiled code. It might be worth adding this information to the
output of g.version.
Ultimately, the only place where the actual off_t size is "known" is
in compiled code. It might be worth adding this information to the
output of g.version.
Ultimately, the only place where the actual off_t size is "known" is
in compiled code. It might be worth adding this information to the
output of g.version.
Thanks, but the g.version is a bit difficult to be run from in CMAKE
script. Could be the output of g.version written to a header file?
E.g. run g.version -g > include/build_version.h when manual pages are
generated?