Helmut Kudrnovsky wrote:
"Finally I found it, it is similar story like with FILE.
The provider (MSVC) calls Vect__open_old with struct Map_info variable
allocated in the provider where sizeof(struct Map_info) = 1408.
Vect__open_old (MinGW) calls G_zero on that variable, where
sizeof(struct Map_info) = 1520.
It means that all structures used in GRASS libs must be also allocated
in GRASS. New functions like Vect_alloc_map have to be added to GRASS
and until it gets to GRASS and to OSGeo4w, the the structures must be
be allocated in the provider with enough space.
Strange thing that it came up only now with GRASS 7 and threads.
You need to get both compilers to use the same ABI.
The "alternative" is to treat all structures as opaque, which isn't
going to happen. It isn't sufficient to have GRASS allocate and free
everything, you also can't access any fields directly, you'd need
setters and getters for everything.
Given the numbers, my first guess is that MinGW is using 8 bytes for
off_t versus 4 bytes for MSVC. Yep; the bottom of config.h.in has:
#if defined(__MINGW32__)
/* add/remove as needed */
/* redefine off_t */
#include <sys/types.h>
#define off_t off64_t
And that's unaffected by --disable-largefile.
This specific issue may just need changing __MINGW32__ to WIN32 (or
_WIN32 or _WINNT, all of which are defined by MinGW) so that MSVC gets
the same treatment. Failing that, some way to disable LFS (e.g. making
MinGW builds honour --disable-largefile) is needed.
The FILE issues are presumably due to mismatches between different
versions of the MSVCRT library. malloc() and free() have the same
issue: heap data must be freed by the same version of MSVCRT which
allocated it (NVIZ originally had issues with passing Tcl_Alloc()d
pointers directly to free() instead of Tcl_Free(), which fails if Tcl
uses a different version of MSVCRT to GRASS).
I don't know whether it's possible to change the version of MSVCRT
which MinGW uses. If not, then we'll need to look at why files opened
by lib/gis functions are being read/written by user code. But it would
be preferable if FILE* could be passed around.
--
Glynn Clements <glynn@gclements.plus.com>