[gdal-dev] GDAL 1.8 - Switch Thrown
Ari Jolma
ari.jolma at gmail.com
Mon Jan 31 08:27:17 EST 2011
On 01/30/2011 10:39 PM, Tamas Szekeres wrote:
> 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.
Tamas,
First, this page:
http://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/
has an alarming advice: "Therefore [when using stdcall], if you intend
to have binary compatibility between MinGW and MSVC builds of your DLL,
it’s necessary to change the names of the exported functions".
The steps: Download and install your DLL package; download the
respective swig/perl folder (this really should be a separately
downloadable package distro); Edit Makefile.PL to find gdal17.dll; run
perl Makefile.PL; run make.bat.
That assumes of course you have a working perl. Strawberry perl should
be usable as it is MinGW. Also in fact Makefile.PL should find the
import library for which I used gdal17.dll.a, which I created with
pexports and dlltool.
Perl tests are run simply as "make test", which runs the test code
without installing anything.
Jürgen, no I did not yet try .lib.
Ari
>
> Best regards,
>
> Tamas
>
>
> 2011/1/30 Ari Jolma <ari.jolma at gmail.com <mailto: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
>> <mailto: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 <mailto:gdal-dev at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto: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/20110131/3a5acdd2/attachment-0001.html
More information about the gdal-dev
mailing list