[GRASS-dev] Debugging QGIS with GRASS provider on Windows

[Helmut Kudrnovsky]

Radim Blazek-2 wrote
> On Fri, Jun 19, 2015 at 9:44 AM, Maris Nartiss <

> maris.gis@

> > wrote:
>> 2015-06-19 10:35 GMT+03:00 Radim Blazek <

> radim.blazek@

> >:
>>>
>>> I have somehow managed to compile limited GRASS core libs with MSVC
>>> and GRASS Makefiles replacing gcc by cl.exe. The build system does not
>>> seem to be the biggest problem, there are still pieces of code not
>>> compiling under MSVC however.
>>
>> If you are ready to test changes, could you report issues with code in
>> trac? Then it would be possible to check if existing code can be
>> accommodated to compile with both GCC and MSVC.
> 
> I would like to, it was originally my aim to also submit patches, but
> being stressed by time (QGIS release July 26), I am just putting hack
> over hack to get it running and debuggable to be able to fix bugs for
> the release.
> 
> Radim

just for the record the parallel discussion on the OSGeo4W-ML

http://osgeo-org.1560.x6.nabble.com/Crash-in-thread-on-FILE-opened-by-a-lib-compiled-by-MinGW-td5211876.html

 with summary:

"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.

Thanks for your ideas Even and Jef
Radim"







-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Debugging-QGIS-with-GRASS-provider-on-Windows-tp5211308p5212039.html
Sent from the Grass - Dev mailing list archive at Nabble.com.