[GRASS-dev] WinGRASS Wiki Hacking

[Frank Warmerdam]

Glynn Clements wrote:

> I've tried changing it to that, with the same result:
> 
> 	configure:7653: checking for GDALOpen
> 	configure:7679: gcc -o conftest.exe -g    -I/usr/local/include -I/c/progra~1/GnuWin32/include -I/c/OSGeo4W/include  -Wl,--export-dynamic,--enable-runtime-pseudo-reloc  -L/usr/local/lib -L/c/progra~1/GnuWin32/lib -L/c/OSGeo4W/lib conftest.c /c/OSGeo4W/lib/gdal_i.lib -L/c/OSGeo4W/lib -lpng -lz 1>&5
> 	C:/DOCUME~1/glynn/LOCALS~1/Temp/ccAxbaaa.o(.text+0x2b): In function `main':
> 	C:/msys/1.0/home/glynn/grass/configure:7673: undefined reference to `GDALOpen'
> 	collect2: ld returned 1 exit status
> 
> But I've figured it out. The GDAL library was built to use "stdcall",
> which isn't compatible with autoconf tests (AC_CHECK_FUNC etc).
> 
> The autoconf AC_CHECK_FUNC test doesn't use any headers, so it doesn't
> know that the function uses the "stdcall" convention, and also doesn't
> know that its argument list totals 8 bytes (hence the _GDALOpen at 8
> name).
> 
> We would have to write a custom test, using AC_TRY_LINK on a complete
> test program (which includes headers). We would also need to work
> around the CPL_STDCALL definition in cpl_port.h:
> 
> 	#ifndef CPL_STDCALL
> 	#if defined(_MSC_VER) && !defined(CPL_DISABLE_STDCALL)
> 	#  define CPL_STDCALL     __stdcall
> 	#else
> 	#  define CPL_STDCALL
> 	#endif
> 	#endif
> 
> which only uses __stdcall for MSVC.

Glynn,

Hmm, I thought I had dealt with this.  The /c/osgeo4w/include/cpl_config.h
file should start with:

/* We define this here in general so that a VC++ build will publically
    declare STDCALL interfaces even if an application is built against it
    using MinGW */

#ifndef CPL_DISABLE_STDCALL
#  define CPL_STDCALL __stdcall
#endif

The mingw build *should* properly respect this stdcall definition,
and it works for me. Is there any chance you are picking up some other
cpl_config.h instead of the one in /c/osgeo4w/include?  Could you
confirm that the /c/osgeo4w/include/cpl_config.h on your system starts
with the stdcall stuff?

> Or we could just compile GDAL ourselves from source using MinGW, which
> is probably the best solution. 

This is exactly what I'm trying to avoid!

> Although I would rather stick to
> "official" binaries where possible, in this case it's likely to be
> more trouble than it's worth.
>
> Note that PROJ doesn't use stdcall, nor do any of the GnuWin32
> libraries, nor MinGW's own libraries (obviously the import libraries
> for the Windows API do, as that's what Windows' own DLLs use).
> 
> For the most part, using __stdcall is a bad idea. Modern computers
> have rather more than 640KiB of RAM, so shaving a few bytes from each
> function call really isn't that important any more.

stdcall is used so that the GDAL functions can be more easily called
from VB6 and/or delphi as I recall.  It is not done for efficiency
purposes.

>> To get proj to work, I found I had to copy /c/osgeo4w/lib/proj_i.lib to
>> /c/osgeo4w/lib/libproj.a.
> 
> I just added /c/OSGeo4W/bin to the --with-libs= argument, so it links
> directly against the DLL.

I was not aware that this was possible.

>>> I also had to remove the msvcrt.dll from the bin directory, as that
>>> caused -L/c/OSGeo4W/bin to fail (even if you didn't actually use any
>>> libraries) due to multiple definitions of _onexit() and atexit().
>> I think you are barking up the wrong tree here, and there should be
>> no reason to remove msvcrt.dll from the bin directory.
> 
> No, that's definitely necessary if the bin directory is in the library
> path (e.g. for linking directly against DLLs). Otherwise, it won't
> link even the most trivial programs:
> 
> 	$ cat foo.c
> 	int main(void)
> 	{
> 	        return 0;
> 	}
> 	$ gcc foo.c
> 	$ gcc foo.c -L/c/osgeo4w/bin
> 	d000007.o(.text+0x0): multiple definition of `_onexit'
> 	/mingw/lib/crt2.o(.text+0x2d0):crt1.c: first defined here
> 	d000010.o(.text+0x0): multiple definition of `atexit'
> 	/mingw/lib/crt2.o(.text+0x2c0):crt1.c: first defined here
> 	collect2: ld returned 1 exit status
> 	$ mv /c/osgeo4w/bin/{,x}msvcrt.dll
> 	$ gcc foo.c -L/c/osgeo4w/bin

Well, then perhaps the /bin directory should not be in the library
path!

> That isn't necessarily a problem (msvcrt.dll should already be present
> in Windows' system directory), but some people might get bitten the
> same way.
> 
> Anyhow, I'd suggest that we use OSGeo4W's PROJ library, GnuWin32 for
> most of the other libraries, and compile GDAL ourselves, along with
> the hacked XDR library (there doesn't appear to be a standard binary
> for this; GnuWin32's version of libc doesn't appear to have these
> functions).

Ah, I mistook this email exchange to be an interest in actually packaging
wingrass for OSGeo4W.  I see it is not.

I'll return to my corner and wait patiently in the hopes someone shows more
interest participating in OSGeo4W.

Regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org