Please rebuild GDAL with VC2008 instead of VC2010

[jmalik]

Between the 1.9.1 and 1.9.2 gdal package, a compiler switch happened.

The 1.9.1 package was built with VC2008. The 1.9.2 package are built with VC2010.

This creates runtime issues for some packages built on top of gdal. In my case this is a crash in std::string or std::map...

A managed to have an almost working OTB package at the cost of rebuilding ossim and otb with VC2010. VC2008 builds are unusable. Still, I lost something : any executable linked to both otb and Qt will segfault at load time.

Also (out of scope for OSGeo4W, but still worth mentionning), any Debug build with VC2010 shows similar runtime issues and are unusable.

Two different machines shows the same issue, so I'm confident this is only caused by the compiler switch in the GDAL package.

I had no such issues with the previous GDAL builds done with VC2008. That's why I'm kindly requiring a rebuild of the gdal package with VC2008.

(even though I'm still trying to figure out how qgis can work since it is built with VC2008 but on top of VC2010-gdal...)

[jef]

Replying to jmalik:

(even though I'm still trying to figure out how qgis can work since it is built with VC2008 but on top of VC2010-gdal...)

Does otb/ossim use the GDAL C++ API? QGIS only uses the C API (that was done to avoid all the C++ ABI problems you appear to hit; same thing for GEOS btw).

[warmerdam]

I concur with Jurgen - my first advice is to use the GDAL C API. I am not too keen on reverting to VC2008 for GDAL builds, and would much rather reach a point where applications are loosely coupled via use of the C API.

[jmalik]

Thank you both for your inputs, even though it's a bad news for me...

Yes, OTB uses the GDAL C++ API. I originally understood the C-API approach as "if i use gdal C API, then an application built for gdal 1.9.1 will work without rebuild with a gdal 1.9.2 build; if using the C++ API, then I must recompile the app each time gdal is rebuilt". Guess I was missing other pitfalls...

For the record, I solved my Qt issues thanks to this : ​http://qt-project.org/forums/viewthread/1690 by avoiding calls to QString::toStdString and QString::fromStdString as described in the link. The issue is not specific to 64bit builds. I guess this info will be usefull for other OSGeo4W packagers wanting to build a Qt app with VC2010 on top of the current Qt present in OSGeo4W.

[akaginch]

Python binding is also being affected by the switching. After simple writing with Band.WriteArray, Python crashes at the end.