Did anybody else try to use the now standard Visual Studio built GDAL
DLL (which was much discussed some time ago here and is now available
from Tamas' site) in a MinGW environment?
I spent some time a week or two ago on the issue, but I had a hard time,
which AFAIK is because the DLL mixes two function export methods and
thus using the standard tools seems difficult if not impossible (I
already downloaded the sources for latest GNU dlltool and considered
hacking it...)
The best page about the issue I found so far is this:
http://wyw.dcweb.cn/stdcall.htm
Anybody have any ideas? Is my observation about the two export methods
correct and why is that?
Ari
On 01/29/2011 04:59 AM, Frank Warmerdam wrote:
Folks,
I have had good success with the GDAL 1.8 upgrade and I have now thrown
the switch migrating it into the production version of OSGeo4W.
I have upgraded "gdal", "gdal-python", "gdal-mrsid" and "gdal-autotest".
I have yet to upgrade the ecw, and sde related drivers, and I have not
upgraded the java bindings. I will try to work on them tomorrow.
The gdal15dll package was created for backward compatability and should
be automatically pulled in. It seems to be working fine for OpenEV.
I would encourage folks building packages to update, and rebuild them
using the current GDAL. The GDAL include files in C:\OSGeo4W\include
and libraries in C:\OSGeo4w\lib should now be for 1.8.
Note that the new GDAL package is built using Visual Studio 2008
Express instead of 2003. If you are using the C++ API this may cause
issues but if you use the C API it should be invisible.
Let me know of problems.
Best regards,
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
