[GRASS-dev] WinGRASS Wiki Hacking

[Glynn Clements]

Frank Warmerdam wrote:

> >> It includes a somewhat half-baked WinGRASS build I prepared myself
> >> several months ago, based on the wingrass build notes at the time.
> >> Amoung other things, it proves that a MingW built GRASS can use
> >> a VC7.1 built GDAL.
> > 
> > Alas, I'm finding that isn't the case. Any and all attempts to
> > configure GRASS using the OSGeo4W libraries fail with:
> > 
> > 	undefined reference to `GDALOpen'
> > 
> > [This is after I've constructed a working gdal-config from
> > gdal-config.tmpl.]
> > 
> > I have tried both linking against the import library with:
> > 
> > 	-L/c/OSGeo4W/lib -lgdal_i
> 
> Glynn,
> 
> The gdal-config distributed in /c/osgeo4w/bin should return this for
> gdal-config --libs:
> 
> warmerda at gdal3200% gdal-config --libs
> /C/osgeo4w/lib/gdal_i.lib

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.

Or we could just compile GDAL ourselves from source using MinGW, which
is probably the best solution. 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.

> 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 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
	$ 

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).

-- 
Glynn Clements <glynn at gclements.plus.com>