[gdal-dev] GDAL 1.8 - Switch Thrown

[Tamas Szekeres]

Ari,

I would be eager to know the exact use case you have. Did you have some
errors provided by the linker in this case?
It would indeed be a problem how the various compilers decorate their export
functions in a different way. It looks like the __declspec(dllexport) option
(this is what is used in GDAL) provides different names with MSVC and MinGW
by default. If we want to compile the dlls in a portable way we should
probably get back to an alternative method like .def file or "#pragma
comment( linker, "/export:FuncName" )" when exporting the functions.

The article you are referring to describes another way of providing a
portable version that is:
1. Compile the dll as it is now (the functions exported
with__declspec(dllexport))
2. Extract the export functions in a .def file by using pexports
3. Replace the function names with their undecorated names in the .def file
4. Recompile the dll with this new export definition file.

I'm keen to give it a try if I get some further info about how to test this
on the other side.


Best regards,

Tamas




2011/1/29 Ari Jolma <ari.jolma at gmail.com>

> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110129/7fda18b0/attachment.html