[gdal-dev] 1.4.4 Preliminary Win32 Binaries

[Even Rouault]

Hi,

First, I found the following discussion on CPL_STDCALL problems  :
http://www.nabble.com/Windows-linking-to-FWTools-gdal_i.lib-t1128647.html

I think you pointed out exactly where your problem is.

If you look at cpl_port.h, you can see :

#ifndef CPL_STDCALL
#if defined(_MSC_VER) && !defined(CPL_DISABLE_STDCALL)
#  define CPL_STDCALL     __stdcall
#else
#  define CPL_STDCALL
#endif
#endif

So, libgdal compiled with GCC/MSYS will ignore CPL_STDCALL and export symbols 
as 'cdecl' without any symbol decoration.

Whereas, libgdal14.dll compiled by Frank with MVSC 7.1  takes into account 
CPL_STDCALL  and exports these symbols with the _foo at X decorations.

Now, let's play a bit...

I've tried to compile the following c code into a DLL with 
i586-mingw32msvc-gcc (under Linux) :

foo.c :
int __declspec(dllexport) foo_cdecl();
int __declspec(dllexport) foo_cdecl() {}
int __declspec(dllexport) __stdcall foo_stdcall();
int __declspec(dllexport) __stdcall foo_stdcall() {}

Compiled with "i586-mingw32msvc-gcc foo.c -shared -o foo.dll", I get the 
following symbols :

[Ordinal/Name Pointer] Table
        [   0] foo_cdecl
        [   1] foo_stdcall at 0

That confirms what is above. Except, that I would have 
expected "_foo_stdcall at 0" instead of "foo_stdcall at 0".
http://wyw.dcweb.cn/stdcall.htm which appears to be a great reference on that 
subject seems to confirm that GCC and MSVC don't decorate dllexport __stdcall 
symbols the same way...

Now, I've written foo.def to export foo_stdcall at 0 as _foo_stdcall at 0:
DESCRIPTION 'foo'
VERSION 1.0
EXPORTS
foo_cdecl
_foo_stdcall at 0 = foo_stdcall at 0

i586-mingw32msvc-gcc foo.c -c
i586-mingw32msvc-dllwrap --def foo.def -o foo.dll foo.o

And now, I get :	

[Ordinal/Name Pointer] Table
        [   0] _foo_stdcall at 0
        [   1] foo_cdecl

Great victory !

So I guess that even if you change the above portion of cpl_port.h to #  
define CPL_STDCALL     __stdcall to recompile GDAL with gcc, you won't get 
something compatible, unless you use a DEF file and use alias symbols for all 
stdcall functions. Arf, these calling conventions / different compiler issues 
are a nightmare !

Best regards,
Even


Le Saturday 24 November 2007 12:02:58 Ari Jolma, vous avez écrit :
> Frank Warmerdam kirjoitti:
> > Folks,
> >
> > I have prepared 1.4.4 win32 binaries for GDAL based on RC1.  Feel free to
> > use these in testing.
> >
> >   http://download.osgeo.org/gdal/win32/1.4.4
>
> I tried to drop it as a replacement (I had to change the name) to the
> libgdal-1.dll that gcc rpoduces in MSYS. The error message is
> "CPLGetLastErrorMsg could not be located in dll". And, no, I cant see it
> in the gdal14.dll (using the portable executable viewer in servant
> salamander). There is, however, _CPLGetLastErrorMsg at 0. Why is it so,
> when there are for example CPLError (without _ and @0)?
>
> I guess the answer is that in cpl_error.h CPLGetLastErrorMsg has
> CPL_STDCALL and CPLError does not. What's CPL_STDCALL and why is it needed?
>
> Ari
>
> > Best regards,