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:
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 */
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:
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
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 <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
