Compiling the C/C++ support libraries

From gvSIG CE Wiki

Jump to: navigation, search

Note: Make sure to read through and complete all the steps on the page about Setting up the GNU Compiler Collection, before you continue.

GvSIG CE uses some external programs and function libraries that are written in C/C++ instead of Java. These include PROJ.4 for reprojection of spatial data, and the GRASS and SAGA GIS modules (for use from within SEXTANTE). They have to be compiled as "native binaries", i.e. separately for every supported operating system (Linux, Mac OS X and Windows). In addition, to provide direct access from Java (i.e. gvSIG and SEXTANTE) to C /C++ libraries like PROJ.4, a Java Native Interface (JNI) wrapper is needed. Such interfaces need only be provided for those libraries which contain functions that are directly called by the Java application. Indirect dependencies (e.g. GRASS GIS depends on a numbre of external libraries) must be copied into any location where the operating system will be able to find them.

These instructions have been prepared on a Linux system, but everything has also been tried and tested on Windows and Mac OS X. If there are any differences in the steps to perform on these operating systems, they will be explicitely mentioned.

These instructions have been written to work straight from the command line. Linux and Mac OS X systems come with a Unix shell that provides a powerful command line.

On Windows operating systems, you need to install a free C/C++ compiler, plus the GNU make system programs and a POSIX environment that gives you a shell in which to execute configuration scripts. Please refer to the page on Setting up the GNU Compiler Collection for further instructions before you continue with this. These instructions are for the GNU Compiler Collection (GCC) only. Visual C is not covered.

Currently, JNI bindings are needed for the following libraries:

  • PROJ.4 (projection support)
  • Potrace (vectorization of raster layers)

In the following instructions, these libraries will be compiled and installed in order of dependency.

To use them from gvSIG, a version of the compiled C binaries is needed somewhere in the application's search path, plus the compiled JNI wrappers, plus the JNI JAR files. It is necessary to keep all of these synchronized using the same C/C++ source code base. Also, the JNI wrappers may be very sensitive to version changes in the wrapped C/C++ APIs. Therefore, precise library versions are always specified as part of the following instructions.

Note: In the past, gvSIG CE also required its own JNI bindings for GDAL, a library that provides support for a large range of raster data formats, plus two additional sets of bindings for MrSID and ECW format raster support. None of these are required any longer. MrSID and ECW support is now handled by GDAL and gvSIG's own GDAL JNI bindings have been replaced with those that ship with GDAL.



There are a few additional things that must be set up on your system before you can start compiling the native libraries and JNI bindings. Make sure to set up everything as detailed below, so you will be able to successfully follow the instructions and compile the binaries.

Home folder and workspace

Firstly, there is a home directory (folder) which is set automatically by the system and always points to your user directory. On Windows (MSYS), this is not the folder C:\Users\<user name>, but rather the folder /home/<user name> inside your MSYS installation folder! All the following instructions assume that you are working in your home folder or one of its subfolders. No files outside your own home folder will be changed in any way (i.e. no system files will be touched).

If in doubt, you can "change directory" (cd) into your home folder and use the "pwd" command to print the current directory path, as it is seen by your command shell:

 cd "$HOME"

The main working directory, where the source code will be located and into which compiled binaries will be installed, will be referred to as WORKSPACE from now on. This is a shell variable which should point to the actual folder on your hard disk where you have your current Eclipse workspace, e.g.:

 mkdir "$HOME/workspace"
 export WORKSPACE="$HOME/workspace"

If you like, you can make $WORKSPACE point anywhere else you like, but it is most convenient to have direct access to the Java source code of your Eclipse project in the same location.

Some instructions also assume that you have a directory src created in WORKSPACE, into which you download the source code for additional software, and a directory dist, where the compiled binaries, libraries and header files will be copied during software installation:

 mkdir "$WORKSPACE/src"
 mkdir "$WORKSPACE/dist"

All C/C++ code installation targets will be set up so that any library files and headers generated will end up in:



In order to be able to directly run the newly compiled binaries (this is necessary for some of the dependencies we will install later) from the MSYS command line, add the dist/bin directory to your PATH:

 export PATH="$WORKSPACE/dist/bin:$PATH"

Java Development Kit

You need the Java Development Kit (JDK), not just the Java Runtime Environment (JRE), installed and working on your system. Make sure that it is the JDK 1.8 (Java 8), and that it is the OpenJDK version of the JDK (although chances are that everything will work fine with other JDKs). To check whether that is the case, run the Java compiler:

 javac -version

If the output is similar to the below:

 javac 1.8.<n_nn>

(the third part of the version number may vary), then your are good to go. If not, then follow the instructions below to install a suitable version of the JDK on your system.

Either download a binary copy of OpenJDK from the unofficial builds page and install it into any local folder, or use your distribution's package manager to install a system-wide version of Java.

We will use another environment variable, JDK, to point to the folder in which the JDK is located, e.g.:

 export JDK="$WORKSPACE/jdk"

You can also include the bin subfolder of the JDK in the executable search path, so that you can run Java from within any other folder:

 export PATH="$JDK/bin:$PATH"

Note: The following instructions assume that OpenJDK 8 has been installed into $WORKSPACE/jdk. If you are using a system-wide JDK installation, or have installed the JDK anywhere else, then you must adjust $JDK accordingly!

Another shell variable, JDK_HEADER_DIR is used to point to the subfolder of your JDK which has the header files for Java development. In addition, JDK_HEADER_DIR_SYS must point to a folder with include files that are operating system specific (see operation specific instructions below). In most cases, this folder will be called include. You must export WORKSPACE, JDK and JDK_HEADER_DIR to point to valid directories. Otherwise, none of the instructions on this page will work!



 export JDK_HEADER_DIR="$JDK/include"

Mac OS X


 export JDK_HEADER_DIR="$JDK/include"


On Windows, should you wish to set JDK_HEADER_DIR to point to your system-wide installation or local copy of the JDK, you must use the MSYS path notation with "/", instead of the native Windows one with "\", e.g.:

 export JDK_HEADER_DIR="c/Program Files/Java/jdk1.7.0/include"

Apache Ant

If you wish to also build the Java class libraries for the JNI bindings yourself, then you need Apache Ant (a build tool for Java projects).

To check whether your system is already set up to use Ant, just try to run it:


If Ant is properly installed, the output should be:

 Buildfile: build.xml does not exist!
 Build failed

If not, Ant is available for all systems from

For detailed installation instructions, see the Apache Ant user manual.

Things to know about the JNI bindings

The JNI function calls are linked against platform specific C(/C++) object libraries. This is why you have to compile separate versions for each operating system and also separate 32 and 64 bit versions.

Some gvSIG extensions only store references to external libraries in the JNI objects, others ("libjni-proj4") directly store the function code there -- like any other C library might.

To use the JNI bindings, the Java code has to contain a

 System.load.library("<libname>") statement.

This means that the library name is hard-coded on the Java side and the library has to exist with that exact name (plus any library prefixes/suffixes that the operating system might require).

If the JNI library is found, it is treated just like a JAR file and adds all its function interfaces as Java classes. This mechanism is completely platform independent, so the Java side code that works with these JNI classes can be compiled (in this case using Ant) as regular JVM byte code on any OS and will run on any other.

If a JNI library is generated with references to another dynamic library as a dependency, then the name of that library is hard-coded into the JNI library. The dependency library must then be deployed with that exact name, within the system's linker search path (more on that later).

Checking out the source code

Make sure to check out the following projects from the gvSIG CE SVN repository into your WORKSPACE/src folder:

  • build
  • libjni-potrace
  • libjni-proj4

The project folder build contains the CMake macros (see below) that are needed to compile the JNI libraries in the libjni-* project folders.

Note: It is possible to run the Ant build files for all binary projects directly from Eclipse, but in the following instructions, compilation will be done manually, on the command line. This gives better control over the complex process and allows for some fine-tuning.


This is a build system which is required to configure and compile the JNI libraries.

You can download CMake for all operating systems from its home page. CMake 2.8 (latest patch level) is known to work with the current JNI bindings. The minimum version is CMake 2.6.

Important: Make sure to import the "build" project folder as described above. Otherwise, some CMake macros will be missing and there will be error messages about packages "DepMan" and "GeneralMacros" not being found!


On Ubuntu, the following will install CMake straight from the package repository for your distribution:

 sudo apt-get install cmake-curses-gui

On other distributions, check your package manager and distribution documentation.

Mac OS X

When installing for Mac OS X, make sure to have the CMake installer put the links into /usr/bin when asked. This will allow you to easily run "cmake" from the command line.


Go to and download the Windows installer. When asked, tell it to "(o) Add CMake to the system PATH". This will allow you to easily run "cmake" from the command line.

32/64 bit binaries

The main advantage of running Java programs in a 64 bit JVM is that more Java heap space will be available (generally more than twice as much as on a 32 bit JDK), allowing gvSIG to process larger datasets without running out of memory.

Since the Java Bytecode which is contained in the JAR class files is not a specific machine language, but, as the name implies, composed of portable, 8 bit wide instructions, it is perfectly possible to compile Java sources using a Java compiler on a 32 bit system and execute the resulting class binaries on a 64 bit machine, or the other way around. Whether the code will actually run in 32 or 64 bit mode is solely determined by the type of JVM used to execute it.

The situation is more difficult for native binaries produced by a C/C++ compiler, as these are in a machine language that is optimized for a specified CPU type. While it is possible for an entire 32 bit process (i.e. a program) to run on a 64 bit CPU, the reverse is not possible. Also, it is not possible to mix 32 and 64 bit binaries in one and the same process. In the case of gvSIG, this means that gvSIG running in a 64 bit JVM will not be able to e.g. load raster data using a 32 bit GDAL library.

It is therefore necessary that you understand how to produce 32 or 64 bit native binaries from C/C++ source codes, according to your needs.

On newer systems (notably Mac OS X Snow Leopard and Windows with MinGW-win64), the GCC will produce 64 bit code by default. To make it produce 32 bit code instead, export some compiler flags:

 export CFLAGS=-m32

If you don't trust your systems automatic decisions, you can also explicitly set it up for 64 bit compilation:

 export CFLAGS=-m64

These are variables that get read by the configure scripts of the individual libraries, so they have to be exported before any configure script is run in order to take effect.

Likewise, CMake will respect these variables, but they have to be present before running cmake to create the configuration.

Note: Settings CFLAGS and friends might break CMake on Windows/MinGW64 (error message: "g++.exe: No input files"). For some reason, it cripples the command line used to call GCC by CMake (it seems that a line feed or CR is inserted by the CMake macro generator).

Not all software is set up to respect these variables. The instructions on these page will always tell you if there is something else that needs to be done in order to produce 32 or 64 bit binaries.

Note that it is perfectly possible to produce 64 bit binaries on a 32 bit system. You will just not be able to execute 64 binaries on a 32 bit system.

You can check whether a generated binary is 32 or 64 bits by using the file command:

 file <binary-name>

E.g., for Mac OS X 32 bit binaries, this will result in something similar to:

 <binary-name>: Mach-O dynamically linked shared library i386

In this case, the "i386" architecture tag indicates that we have 32 bit code.

On Windows, 64 bit binaries should display this string:

 <binary-name>: PE32+ executable for MS Windows [..]

(the PE+ indicates 64 bit...), while 32 bit binaries display:

 PE32 executable for MS Windows [..]

(PE (no plus) indicates 32 bit: clear as mud, ain't it?).

On systems that use a 64 bit JVM by default (such as Snow Leopard), the "-d32" option has to be appended to the java command in order to switch to a 32 bit JVM.

More information on MinGW (Windows) 64 bit compilation can be found on the SpatiaLite How-to pages.

Additional hints

This section contains some additional hints, that could make your life easier when compiling binaries for different platforms on a regular basis. Note especially the Windows-specific hints. This OS is the most problematic, since its designers obviously did not care about the POSIX standard.

Configuring the environment

If you don't want to export all those variables every time you start a new shell session, you can use a text editor to append them to C:\MSYS\etc\profile (or the $HOME/.bashrc or wherevery your shell stores its user settings). This is how things could be set up on Windows/MSYS:

 alias clear=clsb
 #Compilation environment (64 bit)
 export WORKSPACE="$HOME/workspace"
 export JDK="$WORKSPACE/jdk"
 export JDK_HEADER_DIR="$JDK/include"
 export CFLAGS=-m64
 export PATH="$WORKSPACE/dist/bin:$JDK/bin:$PATH"

Windows notes

Configuring the source code and compiling it can be significantly more tricky and time-consuming on Windows than on Linux and Mac OS X. This is because Linux and Mac OS X share many similarities, including some command line tools and system libraries that are commonly used in open source software development. Windows, on the other hand, ships with none of these and does not implement the POSIX standards that developers on most other operating systems rely on.

We have done our best to document the procedure on Windows in detail. Pay close attention to the precise version numbers mentioned. It is not uncommon for software to compile well on Windows in a specific version only.

MinGW, being originally a Linux/Unix development, produces a Unix format for dynamic libraries. These have the extension ".dll.a" and ".la" and are necessary for the MinGW linker. In addition, the compilation process produces plain ".dll" files, which are the Windows format dynamic linking libraries and must be shipped together with the other gvSIG binaries (note, however, that MinGW-win64 will also happily link against ".dll" files instead of "dll.a" files). In all cases, we have documented how to produce both the ".dll" and ".dll.a" files.

Windows looks for DLL files first in the current directory and then in the executable PATH. Keep this in mind if you wish to try software that depends on DLLs.

Also, remember that MinGW-win64 is set up to compile 64 bit code by default. So make sure to include all 32 bit configure and make switches mentioned in the instructions if you wish to produce 32 bit binaries.

For better control over the process, export the following variables for 32 bit compilation:


For 64 bit compilation:


You can then use --host=$HOST option in most configure scripts to control the build process. Some scripts als want --target instead of --host and sometimes also --build. More information can be found [here].

GNU Autotools

Most of the C/C++ libraries described on this page depend on the GNU Autotools for configuration (this is portable source code which needs to be set up differently depending on operating system and CPU).

To check whether the Autotools are installed on your system, type the following:


If you get an error message about "no input files" then all is OK. Otherwise, follow the installations below to install the GNU Autotools on your system.


If you have followed the instructions on Setting up the GNU Compiler Collection, and you still do not have the Autotools installed, then look for the packages "autoconf", "automake", and "libtool" in your distribution's package manager and install them.

Mac OS X

The Autotools should have been installed as part of the XCode developer's tools.


Unfortunately, working GNU Autotools are not part of the MinGW-w64 package, so we must install them from source.

First, get GNU Autoconf here. Note that the latest version known to work, at the time of writing, was 2.68. Later versions require an update to the M4 macro processor (however, M4 1.4.16 compiles, but does not work). Get the archive file with the ".tar.gz" extension.

Copy the the downloaded file into the home folder of your MSYS installation, and unpack it:

 tar -xzvf autoconf-2.68.tar.gz

To configure the source code (note: a 32 bit version is fine) do:

 cd autoconf-2.68
 ./configure --prefix=/usr --host=i686-w64-mingw32

Then make and install:

 make install

This will install GNU Autoconf in your MSYS distribution.

Now repeat the same steps for GNU Automake, which you can find here. At the time of writing, the latest version of this software was 1.12.

When that is done, repeat the same for GNU Libtool, which you can find here. At the time of writing, the latest version of this software was 2.4.2. If you get a compilation error: make sure that you have installed the GNU Findutils, as described in Setting up the GNU Compiler Collection.


Note: The gvSIG CE JNI bindings are currently based on PROJ.4 version 4.9.2. All PROJ.4 releases can be found here.

The "libjni-proj4" project is more than just a JNI wrapper for the PROJ.4 C sources. It contains modified copies of the complete C and header files of PROJ.4 in src and include. The most important modification is that libjni-proj4/ contains src/libcs2cs.c and include/libcs2cs.h which is a version of the original cs2cs.c that can be compiled as a library object instead of as a command line tool. At the time of writing, there were no other significant differences between this and the original version that ships with PROJ.4, version 4.9.2.

C library

We will compile the C library at this point for two reasons:

  1. We need some additional data files, which will be generated as part of the compilation process.
  2. We are going to need the PROJ.4 C library later, for additional software such as GRASS GIS.

Unpack the main library, download the additional datum shift grids from [ here) and unzip them into proj-4.9.2/nad/.

Note: Configuring and making with the additional datum shift grids in the source tree will produce some extra data files that can be installed later to support NAD27/NAD83 and NZGD49 datum conversions (see below).


Configure the sources and build:

 tar -xzf proj4.9.2.tar.gz
 unzip -d proj-4.9.2/nad/
 cd proj-4.9.2
 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes
 make install

Mac OS X

Proceed as for "Linux" above.


Configure the sources and build:

 tar -xzf proj4.9.2.tar.gz
 unzip -d proj-4.9.2/nad/
 cd proj-4.9.2

For 32 bit compilation, use this configuration line:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes --host=i686-w64-mingw32 --build=i686-w64-mingw32

For 64 bit compilation, use this configuration line instead:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32

Then build and install:

 make install

Note: From this point forward, we will skip the source code extraction steps (using tar or unzip) in the instructions. You still have to extract (unpack) the source code downloads, of course. Just use the command lines above as templates.

JNI wrapper

As the next step, we will compile the JNI version of PROJ.4, to be used directly by gvSIG CE.


Generate Makefile for target system using CMake and build :

 cd $WORKSPACE/src/libjni-proj4
 rm CMakeCache.txt
 cmake .

To install, simply copy the library:

 cp lib/ $WORKSPACE/dist/lib

Mac OS X

Proceed as for "Linux" above.

To install, simply copy the library:

 cp lib/libcrsjniproj.jnilib $WORKSPACE/dist/lib


Generate the Makefile for the target system using CMake and build the sources:

 cd $WORKSPACE/src/libjni-proj4
 rm CMakeCache.txt
 cmake -G "MSYS Makefiles" .

This should create the JNI library. It will be stored in bin/libcrsjniproj.dll. Copy and rename it manually:

 cp bin/libcrsjniproj.dll $WORKSPACE/dist/bin/crsjniproj.dll


If at this point you get an error message like this one when running "cmake":

 CMake Error at CMakeLists.txt:38 (FIND_PACKAGE):
   Could not find module FindDepMan.cmake or a configuration file for package
   Adjust CMAKE_MODULE_PATH to find FindDepMan.cmake or set DepMan_DIR to the
   directory containing a CMake configuration file for DepMan.  The file will
   have one of the following names:

Then you have not checked out the "build" project into your WORKSPACE, as instructed earlier, and should do so now.


This software provides a vectorization engine for raster layers. It is used as a processing back-end by gvSIG CE's raster "Vectorization" tool.

Updating the sources

Like the PROJ.4 JNI library, the Potrace source code is bundled within "libjni-potrace". To update the the Potrace sources, download the latest version from here, then go to the src folder of the downloaded archives, and extract all files, except and to $WORKSPACE/src/libjni-potrace/src/main/native/jpotrace. Overwrite any existing files.

Edit the file $WORKSPACE/src/libjni-potrace/src/main/native/jpotrace/CMakeLists.txt', and insert the appropriate version value (e.g. for Potrace version 1.9):


C library

Generate Makefile for target system using CMake and build:

 cd $WORKSPACE/src/libjni-potrace
 rm CMakeCache.txt
 cmake .

This should create the JNI library.

Note: If there are any compiler errors about malformed strings (such as “expected ')' before 'potrace'”, produced by bad string replacement. Open the affected files and replace occurences of:


with their C string values:

 potrace, 1.9, mkbitmap

Note: If you get errors about "<config.h>" not being found: edit the files $WORKSPACE/src/libjni-potrace/src/main/native/jpotrace/getopt.c and $WORKSPACE/src/libjni-potrace/src/main/native/jpotrace/getopt1.c. Find the lines that include "<config.h>:

 #include <config.h>

... and replace the pointy brackets (<>)with quotation marks ("), so that the config.h will be picked up from the local directory:

 #include "config.h"

Linux notes

The resulting library file needs to be copied and renamed:

 cp $WORKSPACE/src/libjni-potrace/lib/ $WORKSPACE/dist/lib/

Mac OS X notes

The resulting library file needs to be renamed:

 cp $WORKSPACE/src/libjni-potrace/lib/libjpotrace001.jnilib $WORKSPACE/dist/lib/libjpotrace.jnilib

Windows notes

Generate the Makefile for the target system using CMake and build the sources like this:

cd $WORKSPACE/src/libjni-proj4
rm CMakeCache.txt
cmake -G "MSYS Makefiles" .

This should create the JNI library. It will be stored in bin/libcrsjniproj.dll. Copy and rename it manually:

cp bin/libjpotrace001.dll $WORKSPACE/dist/bin/jpotrace001.dll

Java library

 cd $WORKSPACE/src/libjni-potrace

The jar file "jpotrace-0.0.1.jar" can be found in $WORKSPACE/src/libjni-potrace/jar-dist.

GDAL dependencies

Perhaps the most important native C library is GDAL/OGR, which supplies many GIS data format drivers for gvSIG, GRASS and SAGA. GDAL is itself a complex project that depends on other C libraries. In this section, you will be stepped through compiling each one of them before you can create GDAL, it JNI wrapper and the GDAL Java classes for gvSIG.

Note: Make sure that you have successfully compiled and installed PROJ.4 as described here!

Note: On Windows, building the GDAL library together with all its dependencies can be a long and hard task. To automate this process, a build script has been created that compiles and installs all the GDAL dependencies as well as GDAL itself into $WORKSPACE. You can get this bash script from the SVN repository: This script assumes that swig is already installed in the system and that the following files exist in the same directory as the script itself:

  • jni_md.h
  • expat-2.1.0.tar.gz
  • sqlite-autoconf-3071700.tar.gz
  • zlib-1.2.7.tar.gz
  • geos-3.3.6.tar.bz2
  • proj-4.8.0.tar.gz
  • openssl-1.0.1c.tar.gz
  • postgresql-9.2.2.tar.gz
  • gdal-1.10.0.tar.gz

NOTE: Currently this script builds GDAL without support for MrSID and ECW.

To run, simply execute it from the directory that contains the bash script:

 $ ./


SWIG generates interfaces between C/C++ code and a variety of other programming languages. It is required for the GDAL JNI bindings.

SWIG depends ond PCRE, a library for handling regular expressions. It is possible to automatically install a static version of PCRE, for use exclusively by SWIG. First, download and unpack the source code distribution of SWIG. Then download the most recent version of the PCRE source code (in .tar.gz format) from and place it into to the SWIG main folder (no need to unpack the PCRE source code archive). Then run the script from within that folder, e.g.:

 cd $WORKSPACE/src/swig-2.0.11
 wget -c
 sh Tools/

This will unpack and compile PCRE. We can now continue to compile the actual SWIG:

 ./configure --prefix=$WORKSPACE/dist --with-java=$JDK/bin --with-javaincl=$JDK/include
 make install

Note that SWIG may find other supported languages on your system and decide to enable support for them, as well. This won't hurt. But all we need from SWIG for our purposes is Java support.

After the "make install" step has completed, check that SWIG is now accessible from the command line:

 swig -version

This should output the precise version of the SWIG tool that you just installed.

Windows notes

Use the same command sequence as described above for building a SWIG binary for use inside MSYS. Note that this might always produce a 32 bit SWIG tool, even on a 64 bit Windows, but that is fine, since SWIG is only used a an external source code processor.


This is a very light weight and robust XML parser that is required by many GDAL/OGR drivers (see below, e.g. for KML support).


Building and installing this is simple:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes
 make install

Mac OS X

Proceed as for "Linux" above.


For 32 bit compilation:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes --host=i686-w64-mingw32 --build=i686-w64-mingw32

For 64 bit compilation:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32

Then make and install:

 make install

The library will be installed into $WORKSPACE/dist/lib.


SQLite is a compact, file-based DBMS that can also be used by GDAL/OGR to store spatial data in several formats, which is in turn supported by gvSIG CE. It is also used by GRASS GIS for attribute data storage.

There are several versions of the SQLite sources. The one used here is the package that includes the "autoconf"-generated scripts. At the time of writing, this was:


After downloading and unpacking into $WORKSPACE, do:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-readline=no
 make install

Mac OS X

Proceed as for "Linux" above.


For 32 bit compilation:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-readline=no --host=i686-w64-mingw32 --build=i686-w64-mingw32

For 64 bit compilation:

 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-readline=no --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32

Then make and install:

 make install


This is a data compression library that is required by several other libraries.


Zlib (libz) is part of the operating system.

If you want to build your own binaries, anyway, then simply do:

 ./configure --prefix=$WORKSPACE/dist
 make install

You can remove the static library:

 rm $WORKSPACE/dist/lib/libz.a

Mac OS X

See Linux.


As of Zlib version 1.2.5, you can no longer use the configure script on Windows. Instead, run the provided Windows Makefile directly:

 make -f win32/Makefile.gcc

(Be sure to run above command from the root folder of the Zlib sources.)

After compilation, install the binaries manually:

 cp -iv zlib1.dll $WORKSPACE/dist/bin
 cp -iv zconf.h $WORKSPACE/dist/include
 cp -iv zlib.h $WORKSPACE/dist/include
 cp -iv libz.a $WORKSPACE/dist/lib
 cp -iv libz.dll.a $WORKSPACE/dist/lib

Note: use this command line to clean the sources if needed:

 make -f win32/Makefile.gcc clean

GEOS (currently disabled)

The Geometry Engine Open Source (GEOS) is a C++ port of the [Java Topology Suite (JTS)]. It provides advanced topological data query functions to applications such as GDAL, GRASS GIS and PostGIS.

Since it is unclear, how important GEOS really is (it is not essential for GDAL/OGR), and since it does not yet compile well on Windows (see below), we will disable support for GEOS in our binaries until the situation on Windows improves.

Note: Since other software depends on GEOS functioning correctly, these instructions include a "make check" step. Your build of GEOS is only usable if all tests are passed!


 ./configure --prefix=$WORKSPACE/dist --enable-static=no --enable-shared=yes
 make check
 make install

Mac OS X



Note: It is currently (still: 2014-09-05) not possible to configure and compile GEOS on MinGW so that the resulting binaries will pass the "make check" stage without errors. The problem seems to be that the "configure" script does not detect/set all machine-dependent options correctly on MinGW-w64. At the same time, CMake support for MSYS makefiles does not seem to be complete.

The current recommendation is to use CMake:

 rm CMakeCache.txt
 make test
 make check
 make install

Unfortunately, this does still not result in fully working binaries. The "make test" step will fail at the first test "geos_unit", while the remaining tests will pass.

The library will be installed into $WORKSPACE/dist/lib.


This is a library for secure, encrypted connections that is required by PostgreSQL (see below).

Note: A perfectly working OpenSLL library is essential for secure database connections. Therefore, these instructions include a "make test" step that makes sure that the encryption works flawlessly. Your binaries are only acceptable if the "make test" stage completes without errors!


Note that OpenSSL comes with a slight different configuration system, so make sure to type in the commands exactly as shown here:

 ./config --prefix=$WORKSPACE/dist shared zlib-dynamic -I$WORKSPACE/dist/include
 make test
 make install

The config script tries to guess the right OS and CPU type. If this fails, you will get an error message during compilation which says:

 CPU you selected does not support x86-64 instruction set

In that case, force the right CPU type by either appending -m32 or -m64 to the configuration line above.

Note also that we build a static version only, because we only need this library for PostgreSQL.

Mac OS X

Configure and make as follows:

 ./Configure darwin64-x86_64-cc --prefix=$WORKSPACE/dist shared zlib-dynamic -I$WORKSPACE/dist/include -m64
make test
make install


Compilation of PostgreSQL with static OpenSSL libraries does not work on Windows, so we produce shared libraries instead. This just means we will have to copy some additional DLLs when distributing binaries.

For 32 bit binaries:

 ./config --prefix=$WORKSPACE/dist shared zlib-dynamic -I$WORKSPACE/dist/include -m32

After the config script has run, 32 bit DLL building also has to be enabled (skip this step if you are building for 64 bit). Edit the file Makefile.shared and append the "pe-i386" target to the "windres" call (ca. line 296):

 	$(PERL) util/ $$dll_name | \
 		$(CROSS_COMPILE)windres --target=pe-i386 -o rc.o; \
 	extras="$$extras rc.o"; \
 	ALLSYMSFLAGS='-Wl,--whole-archive'; \

For 64 bit binaries, just do (note the global "configure"):

 configure mingw64 --prefix=$WORKSPACE/dist shared zlib-dynamic -I$WORKSPACE/dist/include -m64

Then make and install:

 make test
 make install


PostgreSQL is one of the most popular open source client/server DBMS. Together with PostGIS, it can act as a powerful spatial DBMS. We require only the PostgreSQL client library, so that GDAL/OGR can have access to data stored in PostgreSQL/PostGIS.


Configure the sources, make and install:

 ./configure --prefix=$WORKSPACE/dist --without-readline --with-openssl --with-includes=$WORKSPACE/dist/include/ --with-libs=$WORKSPACE/dist/lib/
 make install

This will also create all the PostgreSQL executable programs. But we really only need the client library.

Mac OS X

Proceed as for "Linux" above.


Note: PostgreSQL versions before 9.2.2 will not compile successfully under MinGW-w64.

32 bit binaries

Configure the sources like this::

 ./configure --prefix=$WORKSPACE/dist --without-readline --with-openssl --with-includes=$WORKSPACE/dist/include --with-libs=$WORKSPACE/dist/lib --host=i686-w64-mingw32 --build=i686-w64-mingw32 --build=i686-w64-mingw32

Then simply build and install the software:

 make install

64 bit binaries

Configure the sources like this:

 ./configure --prefix=$WORKSPACE/dist --without-readline --with-openssl --with-includes=$WORKSPACE/dist/include/ --with-libs=$WORKSPACE/dist/lib/ --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32

Then build and install the software:

 make install

Copying the DLLs

In order to be able to run "psql.exe" you need to copy (and rename) two libraries:

 cp $WORKSPACE/dist/lib/libpq.dll $WORKSPACE/dist/bin/

You can now test the binaries:


(On a system that does not have a PostgreSQL server running, this will just give an error message.)

ECW (deprecated)

NOTE: ECW support is now deprecated and will no longer be included in new releases of gvSIG CE!. The reasons for this decision can be read below. These instructions will remain on our wiki for a while but will eventually be deleted. Removing ECW support is part of an on-going effort to clean gvSIG CE from all closed-source, proprietary components.

This library adds support for the ECW raster data format to gvSIG CE (via GDAL).

Note: The ECW file format and the SDK used to support ECW are subject to numerous software patents and restrictive licensing. Long-term support by gvSIG CE for this file format is therefore not possible.

Explanation for above note: The ECW SDK version 3.3, released in 2006, uses a "GPL-friendly" license that allows GPL'd projects, such as gvSIG CE, to distribute the SDK, both in its modified form and with limited patches, under the terms of the "ECW JPEG 2000 SDK PUBLIC USE LICENSE AGREEMENT". Later versions of the SDK use even more restrictive licensing terms and can no longer be re-distributed; they are also no longer available in source code form.

Version 3.3 of the SDK is no longer available for download from the ERDAS (now incorporated intop Intergraph) website. However, the source code is still available in some odd places (here is a link that still seems to be working).

First, download the ECW SDK's source code archive and unpack it, then patch the sources, as described below:

Over the years, some patches have emerged that fix the worst problems in the SDK. They have been accumulated at the Arch Linux User Repository (AUR; see here).

Get the AUR patches ( and unpack them. You will find a new folder libecwj2 that contains a number of patch files with the extension ".patch".

Copy all patch files into the SDK's source folder:

 cp libecwj2/*.patch libecwj2-3.3/

Now apply the patches exactly in the order below (do not apply the "nolcms" patch!):

 cd libecwj2-3.3
 patch -p0 < libecwj2-3.3-3245a.patch
 patch -p0 < libecwj2-3.3-3245b.patch
 patch -p0 < libecwj2-3.3-NCSPhysicalMemorySize-Linux.patch
 patch -p0 < libecwj2-3.3-2593.patch
 patch -p0 < libecwj2-3.3-wcharfix.patch

(You can safely apply all patches on all operating systems.)

The next step is to configure and compile the patched source code:

 ./configure --prefix=$WORKSPACE/dist --enable-shared=yes --enable-static=no
 make install

Note: The configuration script looks for "libz", "libjpeg" and "libtiff" on the system, but in the end does not seem to link to any of those.

The compilation process is messy, with many warnings. Ignore them.

Linux notes

The shared libraries will be called libNCS*.so(.*).

Windows notes

The ECW driver libs cannot be built with MinGW/GCC.

Mac OS X notes

Out-of-the-box, this does not compile on Mac OS 10.6 (Snow Leopard).

Get the code and patch from Patch as instructed on that page, then compile and install like this:

 ./configure --prefix=$WORKSPACE/dist --enable-shared=yes --enable-static=no
 make install

MrSID (deprecated)

NOTE: MrSID support is now deprecated and will no longer be included in new releases of gvSIG CE! The reasons for this decision can be read below. These instructions will remain on our wiki for a while but will eventually be deleted. Removing MrSID support is part of an on-going effort to clean gvSIG CE from all closed-source, proprietary components.

Note: Recent versions of the MrSID SDK binaries are no longer compatible with MingW/GCC. Therefore, GDAL cannot be built with MrSID support using an open source compiler toolchain. It also appears that the latest version of the SDK is no longer available for Mac OS X.

This library adds support for the MrSID raster data format to gvSIG CE (via GDAL). Starting with version 8.0 of the SDK, there is support for MrSID Generation 4 files (both raster and LiDAR data), and JPEG 2000 files.

The source code cannot be downloaded. This API is proprietary and binary-only. Register and download from The licensing restricts the use of the free SDK to read-only applications, but it allows re-distribution of the unaltered, binary SDK files.

There are several versions for different platforms, 32 and 64 bit. Download the "Unified SDK" to get support for all file formats.

Note: the binaries are statically linked to all dependencies, so there will be no additional libraries to install.

All that is needed are the library (for the respective platform) and the header files. The SDK packages contain two directories Raster_DSDK and Lidar_DSDK. Each of them contains one include and one lib directory. The contents of the lib folders have to be copied into $WORKSPACE/dist/lib/. The contents of the include folders go into $WORKSPACE/dist/include/. Do not copy the libgeos files. They are not required for MrSID format support and would only conflict with our own GEOS libraries.

Macintosh Notes

There are binaries for Mac OS X 10.7 ("darwin11") and 10.8 ("darwin12"). Here, we use the 10.7 binaries as they should also work fine on 10.8 and above.

Windows Notes

There are binaries for Visual C 9 and Visual Studio 10. Here, we use the "VC9" binaries.


  • Current version used for binaries: 1.11.0.
  • Download from:
  • Depends on: Expat, SQLite, PostgreSQL

GDAL is a collection of GIS data format readers and writers ("drivers"), written in C++, that is used by most open source GIS projects. We will compile a version that also allows access to GIS data stored in SQLite and PostgreSQL databases.

It is important to compile GDAL with the same capabilities (i.e. supported formats/drivers) on all platforms. Otherwise, gvSIG CE projects created on one platform may not work with a gvSIG CE version running on another platform!

Code Hygiene

GDAL compilation may fail if header files and/or libraries from older GDAL installations are picked up during the process. If you have set a global compiler include path, now is the right time to unset it:


Unfortunately, GDAL does not install its header files in its own subfolder within the target location's "include" folder, and it also does not offer a clean "make uninstall". To remove a previous GDAL installation, delete header files and libraries by hand:

 rm $WORKSPACE/dist/include/gdal*
 rm $WORKSPACE/dist/include/ogr*
 rm $WORKSPACE/dist/include/cpl*
 rm $WORKSPACE/dist/lib/libgdal*

To also remove previously installed executables:

 rm $WORKSPACE/dist/bin/gdal*
 rm $WORKSPACE/dist/bin/ogr*

C++ library

We will compile a light-weight version of GDAL that contains only the most important drivers, available as open source on all platforms. Also, wherever possible, GDAL's internal copies of support libraries are used (LZW, TIFF, PNG,...).

Note: Linking against SQLite3 (as discussed here) gives support for reading rasters in RasterLite format, as well as reading and writing geometries in existing SpatiaLite DBs. For writing RasterLite data and creating/updating SpatiaLite DBs, linking against SpatiaLite is required. However, reading and writing geometries in OGR's WKB/WKT standard is fully support without SpatiaLite support. Here, we will not include SpatiaLite writing support.

Note: Having older versions of the GDAL lib and include files in $WORKSPACE/dist can lead to compilation errors. Make sure to remove any outdated files before compilation.

Configure GDAL:

 ./configure --prefix=$WORKSPACE/dist --enable-shared=yes --enable-static=yes --with-python=no --with-xerces=no --with-expat=$WORKSPACE/dist --with-curl=no --with-sqlite3=$WORKSPACE/dist --with-odbc=no --with-mysql=no --with-oci=no --with-pg=$WORKSPACE/dist/bin/pg_config --with-geos=no --with-libz=internal --with-png=internal --with-libtiff=internal --with-geotiff=internal --with-jpeg=internal --with-gif=internal --with-jasper=no --with-mrsid=no --with-mrsid_lidar=no --with-ecw=no --with-pcraster=internal --with-xml2=no --with-java=$JDK --with-threads=yes

Note the --enable-static=yes setting. We want an additional, static version of GDAL for GRASS' "r.external" module to work: This will allow direct linking to GDAL data sources in the SEXTANTE/GRASS plug-in, which is a significant performance improvement.

Note: We need to enable thread support to safely use GDAL via JNI.

The result should look much like this (check the supported formats to make sure everything is included):

 GDAL is now configured for [your OS here]
 Installation directory:    <$WORKSPACE>/dist
 C compiler:                gcc [-ARCH] -msse -DHAVE_SSE_AT_COMPILE_TIME
 C++ compiler:              g++ [-ARCH] -msse -DHAVE_SSE_AT_COMPILE_TIME
 LIBTOOL support:           yes
 LIBZ support:              internal
 LIBLZMA support:           no
 GRASS support:             no
 CFITSIO support:           no
 PCRaster support:          internal
 LIBPNG support:            internal
 DDS support:               no
 GTA support:               no
 LIBTIFF support:           internal (BigTIFF=yes)
 LIBGEOTIFF support:        internal
 LIBJPEG support:           internal
 12 bit JPEG:               yes
 12 bit JPEG-in-TIFF:       yes
 LIBGIF support:            internal
 OGDI support:              no
 HDF4 support:              no
 HDF5 support:              no
 NetCDF support:            no
 Kakadu support:            no
 JasPer support:            no
 OpenJPEG support:          no
 ECW support:               no
 MrSID support:             no
 MrSID/MG4 Lidar support:   no
 MSG support:               no
 GRIB support:              yes
 EPSILON support:           no
 WebP support:              no
 cURL support (wms/wcs/...):no
 PostgreSQL support:        yes
 MySQL support:             no
 Ingres support:            no
 Xerces-C support:          no
 NAS support:               no
 Expat support:             yes
 libxml2 support:           no
 Google libkml support:     no
 ODBC support:              no
 PGeo support:              no
 FGDB support:              no
 MDB support:               no
 PCIDSK support:            internal
 OCI support:               no
 GEORASTER support:         no
 SDE support:               no
 Rasdaman support:          no
 DODS support:              no
 SQLite support:            yes
 PCRE support:              no
 SpatiaLite support:        no
 DWGdirect support          no
 INFORMIX DataBlade support:no
 GEOS support:              no
 Poppler support:           no
 Podofo support:            no
 OpenCL support:            no
 Armadillo support:         no
 FreeXL support:            no
 SWIG Bindings:             no
 Statically link PROJ.4:    no
 enable OGR building:       yes
 enable pthread support:    yes
 enable POSIX iconv support:yes
 hide internal symbols:     no

If everything looks like the above, compile and install:

 make install

For a quick test, the raster and vector formats supported by the produced GDAL/OGR lib can be listed:

 $WORKSPACE/dist/bin/gdal-config --formats
 $WORKSPACE/dist/bin/ogrinfo --formats

You should also test "gdalinfo" and "ogrinfo" on some sample raster and vector data, respectively.

Mac OS X notes

GDAL 1.11 builds without problems using the same configuration options as in the Linux case.

Windows notes

GDAL is a complex library with many dependencies. Recent versions of GDAL compile well on Windows with MinGW's GCC, but there are some problems with the linking. GDAL's libtool support is broken on MinGW, so some manual work is necessary to get the dynamic GDAL DLL on Windows.

To automate this process, a build script has been created that compiles and installs the GDAL library as well as all the GDAL dependencies into $WORKSPACE. You can get this bash script from the SVN repository: This script assumes that swig is already installed in the system and that the following files exist in the same directory as the script itself:

  • jni_md.h
  • expat-2.1.0.tar.gz
  • sqlite-autoconf-3071700.tar.gz
  • zlib-1.2.7.tar.gz
  • geos-3.3.6.tar.bz2
  • proj-4.8.0.tar.gz
  • openssl-1.0.1c.tar.gz
  • postgresql-9.2.2.tar.gz
  • gdal-1.10.0.tar.gz

To run, simply execute it from the directory that contains the bash script:

 $ ./

The instructions below detail all manual steps performed in the automatic process to build the GDAL library once the dependencies have been built.

To compile 32 bit binaries, configure the sources using this command line:

 ./configure --prefix=$WORKSPACE/dist --enable-shared=yes --enable-static=yes --with-python=no --with-xerces=no --with-expat=$WORKSPACE/dist --with-expat-lib=-L$WORKSPACE/dist/lib --with-curl=no --with-sqlite3=$WORKSPACE/dist --with-odbc=no --with-mysql=no --with-oci=no --with-pg=$WORKSPACE/dist/bin/pg_config --with-geos=no --with-libz=internal --with-png=internal --with-libtiff=internal --with-geotiff=internal --with-jpeg=internal --with-gif=internal --with-jasper=no --with-mrsid=no --with-mrsid_lidar=no --with-ecw=no --with-pcraster=internal --with-xml2=no --with-threads=yes --host=i686-w64-mingw32 --build=i686-w64-mingw32 --without-libtool --enable-fast-install

To compile 64 bit binaries, configure the sources using this command line:

 ./configure --prefix=$WORKSPACE/dist --enable-shared=yes --enable-static=yes --with-python=no --with-xerces=no --with-expat=$WORKSPACE/dist --with-expat-lib=-L$WORKSPACE/dist/lib --with-curl=no --with-sqlite3=$WORKSPACE/dist --with-odbc=no --with-mysql=no --with-oci=no --with-pg=$WORKSPACE/dist/bin/pg_config --with-geos=no --with-libz=internal --with-png=internal --with-libtiff=internal --with-geotiff=internal --with-jpeg=internal --with-gif=internal --with-jasper=no --with-mrsid=no --with-mrsid_lidar=no --with-ecw=no --with-pcraster=internal --with-xml2=no --with-threads=yes --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --without-libtool --enable-fast-install

(Note the "-L" switch for the "--with-expat-lib option": This is required for MinGW configuration.)

The result should look identical to the Linux configuration result above (except for the missing "LIBTOOL support").

After configuration, the Makefiles must be adjusted.

MinGW's compiler suite has problems with inputs consisting of too many object files. This will lead to a "Bad file number" error message during the linking stage.

To get the linking process to work, edit gdal-<version>/GNUmakefile after (!) configuration and rewrite the "$(GDAL_LIB)" target to read (remember: one tab indentation after first line!):

 $(GDAL_LIB): $(GDAL_OBJ) GDALmake.opt
   rm -f libgdal.a
   echo $(GDAL_OBJ) | xargs --max-args=100 $(AR) r $(GDAL_LIB)

Then edit the LIBS definition in the gdal-<version>/GDALmake.opt file to add -lexpat and the $WORKSPACE/dist/bin directory. To do so, simply replace the first -L$WORKSPACE/dist/lib by -L$WORKSPACE/dist/bin (maybe the absolute path appears instead of the $WORKSPACE variable) and add -lexpat at the end:

 LIBS	= $(SDE_LIB) -L$(WORKSPACE)/dist/bin -L$(WORKSPACE)/dist/lib -lsqlite3 -L$(WORKSPACE)/dist/lib -lpq -lpthread -lws2_32 $(KAK_LIBS) $(DWG_LIBS) $(CURL_LIB) \

And finally edit the gdal-<version>/apps/GNUmakefile to add -lexpat to LNK_FLAGS:

 LNK_FLAGS   :=  $(LDFLAGS) -lexpat

Then compile and install the library:


If/when the linker still aborts when trying to make "libgdal.dll", then paste a trimmed version of the link command (replace "<path-to-workspace>" with the contents of $WORKSPACE; remember to link in all required libraries via an "-l" switch):

 x86_64-w64-mingw32-g++ -shared ./frmts/o/*.o ./gcore/*.o ./port/*.o ./alg/*.o ./ogr/ogrsf_frmts/o/*.o ./ogr/ogrgeometryfactory.o ./ogr/ogrpoint.o ./ogr/ogrcurve.o ./ogr/ogrlinestring.o ./ogr/ogrlinearring.o ./ogr/ogrpolygon.o ./ogr/ogrutils.o ./ogr/ogrgeometry.o ./ogr/ogrgeometrycollection.o ./ogr/ogrmultipolygon.o ./ogr/ogrsurface.o ./ogr/ogrmultipoint.o ./ogr/ogrmultilinestring.o ./ogr/ogr_api.o ./ogr/ogrfeature.o ./ogr/ogrfeaturedefn.o ./ogr/ogrfeaturequery.o ./ogr/ogrfeaturestyle.o ./ogr/ogrfielddefn.o ./ogr/ogrspatialreference.o ./ogr/ogr_srsnode.o ./ogr/ogr_srs_proj4.o ./ogr/ogr_fromepsg.o ./ogr/ogrct.o ./ogr/ogr_opt.o ./ogr/ogr_srs_esri.o ./ogr/ogr_srs_pci.o ./ogr/ogr_srs_usgs.o ./ogr/ogr_srs_dict.o ./ogr/ogr_srs_panorama.o ./ogr/ogr_srs_ozi.o ./ogr/ogr_srs_erm.o ./ogr/swq.o ./ogr/swq_expr_node.o ./ogr/swq_parser.o ./ogr/swq_select.o ./ogr/swq_op_registrar.o ./ogr/swq_op_general.o ./ogr/ogr_srs_validate.o ./ogr/ogr_srs_xml.o ./ogr/ograssemblepolygon.o ./ogr/ogr2gmlgeometry.o ./ogr/gml2ogrgeometry.o ./ogr/ogr_expat.o ./ogr/ogrpgeogeometry.o ./ogr/ogrgeomediageometry.o ./ogr/ogr_geocoding.o libgdal.a -L<path-to-workspace>/dist/lib -L<path-to-workspace>/dist/bin -lsqlite3 -lpq -lexpat -lpthread -lws2_32 -Wl,--no-whole-archive -o libgdal.dll

Continue the building process and install:

 make install

Then install the shared and static libraries manually:

 cp libgdal.dll ../../dist/bin/
 cp libgdal.a ../../dist/lib/

Important: Due to linking problems on Windows, the GDAL CLI tools will be linked to the static GDAL library (libgdal.a) by default, making them HUGE (>20MB!). To get smaller binaries, edit the Makefile for the CLI tools in apps/GNUmakefile. Define CONFIG_LIBS above the list of make targets, so that they get linked to the dynamic libraries:

NOTE: The solution below only applies to GDAL 1.10.1. For unknown reasons, it no longer works with GDAL 1.11. Since we do not need to redistribute the full set of GDAL apps, we will simply live with the fact that each .exe is very large for now.

 CONFIG_LIBS=-L${WORKSPACE}/dist/bin -L${WORKSPACE}/dist/lib -lgdal -lws2_32
 gdalinfo$(EXE):	gdalinfo.$(OBJ_EXT)  $(DEP_LIBS)
 	$(LD) $(LNK_FLAGS) $< $(XTRAOBJ) $(CONFIG_LIBS) -o $@

Then recompile the CLI tools and install them manually:

 cd apps
 make clean
 cp *.exe $WORKSPACE/dist/bin

To replace the statically linked tools with the dynamically linked versions.

To test the binaries (very advisable!), run gdalinfo on any GIS dataset supported by GDAL (e.g. a GeoTIFF file).

JNI wrapper

GDAL already comes with officially supported JNI bindings, which we also use for gvSIG CE. To build them we will follow the official instructions:

Linux notes

On Linux, we simply have to set the JAVA_HOME variable correctly in "swig/java/java.opt'".

Edit "swig/java/java.opt" and locate the line that sets JAVA_HOME:

 JAVA_HOME = /some-path

Replace "/some-path" with the actual path of your JDK If you cannot remember the location of your JDK, then issue:

 echo $JDK

Then build the bindings:

 $ cd swig/java
 $ make

There will be some warning, but at the end of the process, you should see:


You can also check that the installation is correct by executing the following command:

 $ java -cp "gdal.jar:build/apps" gdalinfo

This should print the usage instructions for the java version of gdalinfo to the terminal.

Note that you may need to update the LD_LIBRARY_PATH variable to contain $WORKSPACE/dist/bin and $WORKSPACE/dist/lib in order to link the libraries correctly. If it works, install the binaries manually:

 $ cp lib* $WORKSPACE/dist/lib/

Mac OS X notes

On Mac OS X, we first need to set "JAVA_HOME", just as described above, for the Linux case.

In addition, locate the line that sets "JAVA_INCLUDE":

 JAVA_INCLUDE=-I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux

... and replace "linux" with "darwin" at the end of the line.

Then continue as described for Linux, above.

Windows notes

For Windows, we will also follow the official instructions, but with some small modifications:

First, create the file gdal-<version>/swig/java/jni_md.h with the following contents:

 #ifndef _GDAL_JNI_MD_H_
 #define _GDAL_JNI_MD_H_
 #define JNIEXPORT __declspec(dllexport)
 #define JNIIMPORT __declspec(dllimport)
 #define JNICALL
 typedef long jint;
 typedef __int64 jlong;
 typedef signed char jbyte;

Edit the JAVA_HOME variable definition in gdal/swig/java/java.opt to point to the directory in which you have your JDK installed. Normally:


In the same file, change the JAVA_INCLUDE variable to the following value:

 JAVA_INCLUDE=-I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/win32 -I.

In gdal-<version>/swig/java/GNUmakefile, we ensure that the name of the DLLs are not prefixed by "lib", by changing the JAVA_MODULES= libgdaljni.$(SO_EXT)... and $(JAVA_MODULES): %jni.$(SO_EXT)... lines to be:

 JAVA_MODULES = gdaljni.$(SO_EXT) ogrjni.$(SO_EXT) gdalconstjni.$(SO_EXT) osrjni.$(SO_EXT)


 $(JAVA_MODULES): %jni.$(SO_EXT): %_wrap.$(OBJ_EXT)

Finally, we need to modify the $(JAVA_MODULES) rule to include the -D_JNI_IMPLEMENTATION_ -Wl,--kill-at flags, necessary for MinGW, as well as the path to libgdal.dll (remember tabs in makefiles!):

 $(JAVA_MODULES): %jni.$(SO_EXT): %_wrap.$(OBJ_EXT)
     $(LINK) $(LDFLAGS) $(CONFIG_LIBS) -D_JNI_IMPLEMENTATION_ -Wl,--kill-at ../../libgdal.dll -o $@ $(LINK_EXTRAFLAGS)

Then, build the bindings:

 $ cd swig/java
 $ make

There will be many warnings. Ignore them. At the end of the process, you should get:

 Total time: n seconds

You can check the result by executing the following command:

 $ java -cp "gdal.jar;build/apps" gdalinfo

This should print the usage instructions for "gdalinfo".

Finally, install the binaries manually:

 $ cp *.dll $WORKSPACE/dist/bin

NOTE: Currently, the JNI libraries get linked against a static version of the GDAL lib, which makes them very big (>20MB).


  • GDAL: to avoid conflicts with system versions of the TIFF and GeoTIFF libraries, the following configure options can be used:

(this may also be an option for other internal libraries, such as JPEG)

  • GDAL (Windows only): Re-enable dynamic linking of GDAL apps and JNI libraries. The current static linking produces very large binaries.
  • What about support for libLAS? This could be very useful, as there are dedicated GRASS (and SAGA?) modules for handling LiDAR data.
  • Explore the use of --static-libgcc and --static-libstdc++ to produce ultra-portable binaries

Next steps

You are now ready to put together a fully working distribution of gvSIG CE. If you wish to do so now, then go to Running gvSIG CE.

Otherwise, should you also wish to compile your own GRASS and SAGA GIS binaries, then continue with Compiling GRASS GIS or Compiling SAGA GIS.

Previous steps

Go back to Setting up the GNU Compiler Collection.

If you wish to review the MSYS basics (Windows), go back to Getting started with MSYS.