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@12
CPLDefaultErrorHandler = _CPLDefaultErrorHandler@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@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@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.jo...@gmail.com <mailto:ari.jo...@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@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
