[gdal-dev] GDAL 1.8 - Switch Thrown

[Tamas Szekeres]

Ari,

Assuming you did mention to compile the Perl bindings with MinGW could you
describe the steps of the compilation in more detail? (by using the files
downloaded from http://vbkto.dyndns.org/sdk.) Which packages should be
installed as the prerequisites of the compilation?
I admit I'm not an expert in MinGW but it would be quite helpful on my side
to be able to reproduce the issue you are talking about. I would also be
curious to know how the perl tests are executed in this case.

Best regards,

Tamas


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

>  29.1.2011 20:43, Tamas Szekeres kirjoitti:
>
> 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?
>
>
> For the stdcall functions I added entries like this
>
> _CPLDefaultErrorHandler at 12
> CPLDefaultErrorHandler = _CPLDefaultErrorHandler at 12
>
> to the .def file. I create the .dll.a, which is the import library, with
> dlltool from the .def.
>
> There are no errors from the linker. If I leave the stdcall entries as they
> are from pexports, i.e., just
>
> _CPLDefaultErrorHandler at 12
>
> The linker complains about undefined reference to `CPLDefaultErrorHandler'
>
> However, running the Perl tests fail with "The procedure entry point
> CPLDefaultErrorHandler could not be located in the dynamic link library
> gdal17.dll". This is no wonder since the Perl bindings GDAL.dll imports
> CPLDefaultErrorHandler from gdal17.dll. I believe this because I'm misusing
> the .def file or dlltool does not understand that CPLDefaultErrorHandler is
> an alias to _CPLDefaultErrorHandler at 12.
>
> I saw a web page which seemed to say that this is a known problem in
> dlltool and it had a small hack for dlltool.c to fix the problem, but I
> don't find the page just now and I've not yet tried hacking the dlltool.c
> (it seems quite possible).
>
> I think the cdecl functions work ok.
>
> If I compile GDAL in MSYS, all functions are exported cdecl.
>
> Ari
>
>
>
> 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
>>
>
>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> _______________________________________________
> 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/20110130/ae9c3188/attachment.html