[GRASS-dev] WinGRASS Wiki Hacking

[Glynn Clements]

Glynn Clements wrote:

> The stdcall issue could be fixed by avoiding AC_CHECK_FUNC in favour
> of an explicit test program. We already do this for the OpenGL checks,
> as the OpenGL libraries also use stdcall.

I've changed some of the checks to handle libraries which use stdcall. 
The configure script now recognises the OSGeo4W versions of PROJ and
GDAL; however, linking against them fails:

gcc -shared -o /home/glynn/src/grass-svn/dist.i686-pc-mingw32/lib/libgrass_gproj.7.0.svn.dll -L/home/glynn/src/grass-svn/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc  -L/c/progra~1/GnuWin32/lib -L/usr/local/lib -L/c/OSGeo4W/lib     OBJ.i686-pc-mingw32/get_proj.o OBJ.i686-pc-mingw32/do_proj.o OBJ.i686-pc-mingw32/convert.o OBJ.i686-pc-mingw32/datum.o OBJ.i686-pc-mingw32/ellipse.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32    -lz   -lintl  -lproj  /c/OSGeo4W/lib/gdal_i.lib && \
(cd /home/glynn/src/grass-svn/dist.i686-pc-mingw32/lib; ln -f -s libgrass_gproj.7.0.svn.dll /home/glynn/src/grass-svn/dist.i686-pc-mingw32/lib/libgrass_gproj.dll)
Cannot export .idata$4: symbol not found
Cannot export .idata$5: symbol not found
Cannot export .idata$6: symbol not found
Cannot export .text: symbol not found
Cannot export gdal15_NULL_THUNK_DATA: symbol not found
Cannot export proj_NULL_THUNK_DATA: symbol not found
collect2: ld returned 1 exit status

It may just be that we need to add some arcane compiler and/or linker
switches, but I wouldn't have a clue as to what.

On a related note, Windows' odbc32 library works (at least configure
detects it and db/driver/odbc links successfully; I haven't tried
running it).

FWIW, PROJ needed the following patch to build as a DLL:

-------------- next part --------------
diff -ru proj-4.4.9/src/emess.h proj-4.4.9.a/src/emess.h
--- proj-4.4.9/src/emess.h	Thu Mar 18 16:34:52 1999
+++ proj-4.4.9.a/src/emess.h	Thu Jun 26 17:30:47 2008
@@ -16,6 +16,7 @@
 #ifdef EMESS_ROUTINE	/* use type */
 /* for emess procedure */
 struct EMESS emess_dat = { (char *)0, (char *)0, 0 };
+struct EMESS *emess_ptr = &emess_dat;
 
 #ifdef sun /* Archaic SunOs 4.1.1, etc. */
 extern char *sys_errlist[];
@@ -23,8 +24,8 @@
 #endif
 
 #else	/* for for calling procedures */
-
-extern struct EMESS emess_dat;
+extern volatile struct EMESS *emess_ptr;
+#define emess_dat (*emess_ptr)
 void emess(int, char *, ...);
 
 #endif /* use type */
-------------- next part --------------

Essentially, Windows doesn't like auto-importing structure variables
from DLLs. The compiler generates code on the assumption that the
variable's address is a constant, which it isn't if the variable is in
a DLL. So you have to reference the variable through a "volatile"
pointer to prevent certain optimisations.

GDAL needed the following patch:

-------------- next part --------------
diff -ru gdal-1.5.1/GNUmakefile gdal-1.5.1.a/GNUmakefile
--- gdal-1.5.1/GNUmakefile	Fri Dec 21 03:20:10 2007
+++ gdal-1.5.1.a/GNUmakefile	Fri Jun 27 03:13:52 2008
@@ -3,13 +3,13 @@
 
 include GDALmake.opt
 
-GDAL_OBJ	=	$(GDAL_ROOT)/frmts/o/*.o \
-			$(GDAL_ROOT)/gcore/*.o \
-			$(GDAL_ROOT)/port/*.o \
-			$(GDAL_ROOT)/alg/*.o
+GDAL_OBJ	=	frmts/o/*.o \
+			gcore/*.o \
+			port/*.o \
+			alg/*.o
 
 ifeq ($(OGR_ENABLED),yes)
-GDAL_OBJ += $(GDAL_ROOT)/ogr/ogrsf_frmts/o/*.o
+GDAL_OBJ += ogr/ogrsf_frmts/o/*.o
 endif
 
 include ./ogr/file.lst
@@ -229,9 +229,9 @@
 	rm -f $(DESTDIR)$(INST_LIB)/$(GDAL_SLIB_B).$(GDAL_VER)
 	$(INSTALL_LIB) $(GDAL_SLIB) $(DESTDIR)$(INST_LIB)/$(GDAL_SLIB_B).$(GDAL_VER)
 	(cd $(DESTDIR)$(INST_LIB) ; \
-	 ln -s $(GDAL_SLIB_B).$(GDAL_VERSION_MAJOR) $(GDAL_SLIB_B))
-	(cd $(DESTDIR)$(INST_LIB) ; \
 	 ln -s $(GDAL_SLIB_B).$(GDAL_VER) $(GDAL_SLIB_B).$(GDAL_VERSION_MAJOR))
+	(cd $(DESTDIR)$(INST_LIB) ; \
+	 ln -s $(GDAL_SLIB_B).$(GDAL_VERSION_MAJOR) $(GDAL_SLIB_B))
 endif
 
 else
-------------- next part --------------

I suspect that something is getting passed MSys paths, and doesn't
like them. Also, MinGW's "ln -s" just copies the file, so the source
(i.e. the symlink target) must already exist.

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