Get [http://sourceforge.net/projects/mingw/ MinGW], [http://www.mingw.org/wiki/msys MSYS], [http://sourceforge.net/projects/mingw/files/MinGW_API_for_MS-Windows/ w32api], [http://sourceforge.net/projects/mingw/files/ binutils] and install them (this may not be a comprehensive list but start with MinGW and execute the install package and try to add gcc etc. - the tar packages you just unpack to c:\mingw). Then open MSYS prompt, go to the dir where you unpacked GDAL, and issue commands (but see below for configure switches): {{{ ./configure make make install }}} And you should have libgdal-1.dll in your c:\msys\1.0\local\bin and libgdal-1.dll.a in c:\msys\1.0\local\lib. '''Linking issues:''' Edit libtool at line 6114 to sed out the MSYS-anchored absolute path and replace it by a relative path or possibly a Windows drive-based absolute path. or Edit GNUmakefile on lines 6-12 and replace $(GDAL_ROOT) with . (a dot). By default both libgdal.a and libgdal.dll are generated. However, command line utilities such as gdalinfo.exe, etc... will statically link against libgdal.a, instead of libgdal.dll, which leak to huge binary files. You can edit GNUmakefile as such to avoid producing libgdal.a : {{{ Index: GNUmakefile =================================================================== --- GNUmakefile (revision 22722) +++ GNUmakefile (copie de travail) @@ -1,13 +1,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 @@ -28,13 +28,8 @@ $(LD_SHARED) $(GDAL_SLIB_SONAME) $(GDAL_OBJ) $(GDAL_LIBS) $(LDFLAGS) $(LIBS) \ -o $(GDAL_SLIB) -$(GDAL_LIB): $(GDAL_OBJ) GDALmake.opt - rm -f libgdal.a - $(AR) r $(GDAL_LIB) $(GDAL_OBJ) - $(RANLIB) $(GDAL_LIB) - -$(GDAL_SLIB): $(GDAL_OBJ) $(GDAL_LIB) - $(LD_SHARED) $(GDAL_SLIB_SONAME) $(GDAL_OBJ) $(GDAL_LIBS) $(LDFLAGS) $(LIBS) \ +$(GDAL_SLIB): $(GDAL_OBJ) + $(LD_SHARED) $(GDAL_SLIB_SONAME) $(GDAL_OBJ) $(LDFLAGS) $(LIBS) \ -o $(GDAL_SLIB) $(LIBGDAL): $(GDAL_OBJ:.o=.lo) @@ -47,7 +42,7 @@ endif check-lib: port-target core-target frmts-target ogr-target - $(MAKE) $(LIBGDAL-yes) + $(MAKE) $(GDAL_SLIB) port-target: (cd port; $(MAKE)) }}} '''expat:''' By default configure tries to add support for Expat. To enable it, use configure switch --with-expat=/c/mingw, get libexpat.dll and create an import library into /c/mingw/lib with commands (in mingw\bin): {{{ pexports libexpat.dll | perl def.pl >libexpat.def dlltool -d libexpat.def -l ..\lib\libexpat.dll.a }}} where def.pl is a small perl program to add an underscored alias: {{{ while () { $a = $_; print $_; if (/^XML/) { chomp; s/\r//; print '_'."$_ = $a"; } } }}} See also http://trac.osgeo.org/gdal/ticket/2050, i.e., patch configure with {{{ #expat_lib_flags="-L$expat_prefix/lib -lexpat" LIBS="$LIBS -L$expat_prefix/lib -lexpat" }}} before {{{ run_expat_test="yes" }}} in configure. '''GTK+:''' If you have a development version of GTK+ installed, its (old) libtiff may confuse the building. It is best to use --with-libtiff=internal and move tiff headers and libraries away from sight. configure detects GTK+ provided libz, libpng and libjpeg but in compile time zlib.h etc are not found. This correct way to fix this is probably to use --with-jpeg=/c/gtk/include --with-libz=/c/gtk/include --with-png=/c/gtk/include. '''PostgreSQL and PostGIS:''' I've successfully used --with-pg=/c/Progra~1/PostgreSQL/8.2/bin/pg_config '''Wide functions (UTF8 filenames)''' Currently you need to manually define {{{__MSVCRT_VERSION__=0x0601}}} to get wide function support that's built into cpl_vsil_win32.cpp for example in top of GDALmake.opt: {{{ USER_DEFS = -D__MSVCRT_VERSION__=0x0601 }}} '''Misc:''' see this: http://lists.osgeo.org/pipermail/gdal-dev/2010-October/026310.html also, in my environment cpl_config.h does not get correctly created for some reason now, working defines are {{{ #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" #define PACKAGE_URL "" #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define LT_OBJDIR ".libs/" #define STDC_HEADERS 1 #define HAVE_ASSERT_H 1 #define HAVE_FCNTL_H 1 #define HAVE_UNISTD_H 1 #define HAVE_STDINT_H 1 #define HAVE_LIMITS_H 1 #define HAVE_LOCALE_H 1 #define HAVE_VALUES_H 1 #define HAVE_FLOAT_H 1 #define HAVE_ERRNO_H 1 #define HAVE_DIRECT_H 1 #define HAVE_LONG_LONG 1 #define UNIX_STDIO_64 1 #define VSI_LARGE_API_SUPPORTED 1 #define VSI_FTELL64 ftello64 #define VSI_FSEEK64 fseeko64 #define VSI_STAT64 _stat64 #define VSI_STAT64_T __stat64 #define VSI_FOPEN64 fopen64 #define SIZEOF_INT 4 #define SIZEOF_UNSIGNED_LONG 4 #define SIZEOF_VOIDP 4 #define HAVE_IEEEFP 1 #define HOST_FILLORDER FILLORDER_LSB2MSB #define HAVE_VPRINTF 1 #define HAVE_SNPRINTF 1 #define HAVE_VSNPRINTF 1 #define HAVE_ATOLL 1 #define HAVE_STRTOF 1 #define HAVE_GETCWD 1 #define HAVE_DECL_STRTOF 1 }}} '''Python bindings:''' If you use the regular Python Windows binaries, you need to edit $PYTHON_ROOT\lib\distutils\ccompiler.py (at least true for Python 2.7) and change the "_default_compilers" mapping as following, in order GCC to be used instead of MSVC when building the GDAL Python bindings : {{{ _default_compilers = ( # Platform string mappings # on a cygwin built python we can use gcc like an ordinary UNIXish # compiler ('cygwin.*', 'unix'), ('os2emx', 'emx'), # OS name mappings ('posix', 'unix'), # HACK for using mingw GCC ('nt', 'mingw32'), #('nt', 'msvc'), ) }}}