On Fri, Jun 19, 2015 at 7:51 PM, Matthias Kuhn wrote:
> Hi Radim,
>
> Did you check that the internal offsets of the members inside the struct
> are the same?
No I did not and I would not expect that.
> Or are you accessing the members always only in one of the
> two libs?
The data are read via
Hi Radim,
Did you check that the internal offsets of the members inside the struct
are the same? Or are you accessing the members always only in one of the
two libs?
To be honest, this sounds a bit scary...
Cheers
Matthias
On 06/19/2015 07:25 PM, Radim Blazek wrote:
> Finally I found it, it is
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
On Fri, Jun 19, 2015 at 11:32 AM, Even Rouault
wrote:
> Le vendredi 19 juin 2015 11:04:39, Radim Blazek a écrit :
>> Hi,
>>
>> I am trying to fix QGIS (compiled by MSVC) crashes with GRASS 7
>> (compiled by MinGW) on Windows. I have traced down that it crashes
>> when functions are called on a FIL
Le vendredi 19 juin 2015 11:04:39, Radim Blazek a écrit :
> Hi,
>
> I am trying to fix QGIS (compiled by MSVC) crashes with GRASS 7
> (compiled by MinGW) on Windows. I have traced down that it crashes
> when functions are called on a FILE structure which was created by a
> library (libgrass_gis.7.
Hi,
I am trying to fix QGIS (compiled by MSVC) crashes with GRASS 7
(compiled by MinGW) on Windows. I have traced down that it crashes
when functions are called on a FILE structure which was created by a
library (libgrass_gis.7.0.0.dll in this case) compiled by MinGW in a
thread in an application