Thanks Jef. So, fixing the memory issues in grass code isn't avoidable. I'll go on with this (after g.proj, db binaries, v.in.ogr, etc.), because probably this will solve the problems that users are facing from within QGis (various crashes when using the grass plugin). So the real limitation for the end-user, is the possibility to use the complete wxgui (digitizer, nviz), but as Martin is working on this I think this isn't an issue.
The build system is not strict for the end-users collegues: "I want it to work, I don't care how they made it!". This is my boss phrase :) 2009/3/27 Jürgen E. <j...@norbit.de>: > Hi Giovanni, > > On Fri, 27. Mar 2009 at 12:36:43 +0100, G. Allegri wrote: >> the problem on mixing MSVC and MinGW built things (at C level) is >> just a problem of a clean memory management (malloc/free). So, my >> question is: would changing the build system (GNU make -> cmake) solve >> this? Or they're unrelated things? > > Unrelated. > > If everything is compile with the same compiler (ie. using the same > runtime library), that will make the problems disappear again. > > But that's not even true for all the VC built binaries in OSGeo4W (e.g. > QGIS and Qt are build with Visual C++ 2008 Express Edition, while GDAL > and python are built with VC 7.1 - I think). > > AFAICS there's no way around fixing that in GRASS for OSGeo4W. > > The build system currently doesn't support VC at all. I didn't > investigate how intensive it would be to add that to the existing > Makefile, but that might be an option, too. > > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 > Software Engineer D-26506 Norden http://www.norbit.de > > -- > norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH > Rheinstrasse 13, 26506 Norden > GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 > > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev