<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html><head><meta name="robots" content="noindex"> <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> <title>Building GDAL From Source</title> <link href="doxygen.css" rel="stylesheet" type="text/css"> </head><body bgcolor="#ffffff"> <!-- Generated by Doxygen 1.2.3-20001105 on Sat Dec 21 14:02:03 2002 --> <center> <a class="qindex" href="index.html">Main Page</a> <a class="qindex" href="hierarchy.html">Class Hierarchy</a> <a class="qindex" href="annotated.html">Compound List</a> <a class="qindex" href="files.html">File List</a> <a class="qindex" href="functions.html">Compound Members</a> <a class="qindex" href="globals.html">File Members</a> <a class="qindex" href="pages.html">Related Pages</a> </center> <hr><a name="gdal_building"><h2>Building GDAL From Source</h2></a> <p> <center> </center> <p> <a name="unix"></a><h2>Building on Unix</h2> <p> GDAL has been successfully built on Linux, IRIX, Solaris, BSD, and MacOS X. On Unix platforms you might be able to build it as follows (assuming it is unpacked or checked out of CVS as <b>gdal</b>): <p> <pre> % cd gdal % ./configure % make </pre> <p> Some caveats are: <p> <ul> <p> <li> I depend on GNUmake on Unix platforms. Just get and install it if you don't already have it. <p> <p> <li> GDAL shouldn't have many pre-requisite packages. It includes built-in versions of libz, libtiff, libgeotiff, libpng, libgif, and libjpeg if pre-installed versions are not available (or not desirable). <p> <li> There are quite a few optional drivers that depend on <a href="#libraries">external libraries</a>. Use "configure --help" to see the configure options. Some optional libraries include those for GRASS, FITS, OGDI, HDF4, JPEG2000 and ECW. <p> <li> The shared library building is pretty specific to the GNU tool chain. If you are using something different than GNU C++, then you will likely finding that the .so files isn't built successfully. You could just link against the static libraries (normally gdal/gdal.a gdal/ogr/ogr.a gdal/frmts/o/ *.a gdal/gdal.a gdal/port/cpl.a) or you could hack LD_SHARED command in gdal/GDALmake.opt to work on your platform. For the SGI a value of "c++ -shared -all" is often suitable. <p> <p> <li> GDAL, and it's utilities should now build on Cygwin and other platforms where shared libraries are not supported. However, to build your own applications against it, you will need to link against a more extensive set of libraries. The <em>gdal-config --libs</em> command can be used to determine the library set. <p> <p> <li> My "autoconf" logic that checks for libtiff, libpng and libjpeg isn't too savvy about versions. If it is using pre-installed versions of these libraries and this support isn't working, rerun configure with ``--with-png=internal'', ``--with-jpeg=internal'', ``--with-geotiff=internal'' or ``--with-libtiff=internal'' instead. <p> <p> <li> To build on IRIX it is generally necessary to hand modify the GDALmake.opt file resulting from configure, and change "ld -shared" to "ld -shared -all". <p> <p> <li> If you find build problems with one of the format drivers that you don't care about, just remove the format from the GDAL_FORMATS line at the bottom of gdal/GDALmake.opt, do a make clean, and make. This will drop it from the build and default runtime registration. <p> <p> <li> If you are trying to install as other than root (to your own tree set with --prefix) you will likelyhave problems with the python since it always tries to install under the site-packages directory for the installed python tree. If you don't need python support you can supress it at configure using --without-python, or override the python module output directory at configure time with the --with-pymodir=&lt;directory&gt; <p> </ul> <p> <a name="win32"></a><h2>Building on Windows</h2> <p> GDAL can be built on Windows using MS VC++ 6.x and MS Visual Studio .NET (C++) at the DOS command line. For this to work you will normally have to have run the VCVAR32.BAT script that comes with the compiler. For VC 6.x this might be found at: <p> <pre> C:\Program Files\Microsoft Visual Studio\\VC98\\bin\\VCVARS32.BAT </pre> <p> Once the environment is setup, you can cd to the GDAL root directory and do the following: <p> <p> <pre> C:\GDAL&gt; nmake /f makefile.vc </pre> <p> There are lots of options that can be tweaked by hand in the nmake.opt file in the GDAL root directory. <p> <ul> <li> <b>BINDIR</b>: Directory in which to install executables, and DLLs if you use the "nmake /f makefile.vc install" command. <p> <li> <b>PY_INST_DIR</b>: Directory to install python modules in. <p> <li> <b>PYDIR</b>: The directory where your python tree is installed. Used to find python include files. If this is set to a directory that does not exist then python support will be omitted from the build. <p> <li> <b>DLLBUILD</b>: Define this (to "1") to force all the OGR utilities to link against the GDAL DLL instead of building built statically. <p> <li> <b>INCLUDE_OGR_FRMTS</b>: Set to "YES" to build OGR formats into the GDAL dll, or comment out to omit OGR formats from build. <p> <li> <b>SETARGV</b>: Point this to the setargv.obj file distributed with Visual Studio to get wildcard expanasion for commandline arguments or leave commented out to omit this. <p> <li> <b>OPTFLAGS</b>: Set this to contain the desired compiler flags for compiling. The default is a debug build but there is usually a suitable alternative for optimized builds commented out in the template file. <p> <li> <b>ECWDIR/ECWLIB</b>: Uncomment these to enable building with ECW support, correcting ECWDIR to point to the install location on your system. <p> <li> <b>OGDIDIR/OGDIVER/OGDILIB</b>: Uncomment these to enable OGDI support, correcting the OGDIDIR and OGDIVER values as needed. <p> <li> <b>HDF4_DIR</b>: Uncomment, and correct path to enable support for NCSA HDF Release 4. <p> <li> <b>JASPER_DIR/JASPER_INCLUDE/JASPER_LIB</b>: This variables should be pointed to appropriate directories where JasPer library was installed. JasPer toolkit needed for JPEG2000 support. <p> <li> <b>XERCES_DIR/XERCES_INCLUDE/XERCES_LIB</b>: Uncomment these and correct XERCES_DIR to enable Xerces XML parser support for GML read support. <p> <li> <b>FME_DIR</b>: Uncomment, and correct path to enable support for FMEObject vector access. <p> </ul> <p> I frequently forget to update the Windows makefiles when I add new files, so if something comes up missing consider comparing the file lists in the appropriate makefile.vc against the GNUmakefile or just contact me. <p> <p> <a name="libraries"></a><h2>External Libraries</h2> <p> Several drivers require additional libraries to be installed in your system. These are: <p> <ul> <li> NCSA HDF library can be downloaded from the <a href="http://hdf.ncsa.uiuc.edu/">The NCSA HDF Home Page</a> at the <a href="http://www.ncsa.uiuc.edu/"> National Center for Supercomputing Applications</a>. <p> <p> If your OS distribution already contains prebuilded HDF library you can use one from the distribution. <p> <p> Please note, that NCSA HDF library compiled with several defaults which is defined in <em>hlimits.h</em> file. For example, <em>hlimits.h</em> defines the maximum number of opened files: <p> <pre> # define MAX_FILE 32 </pre> <p> If you need open more HDF4 files simultaneously you should change this value and rebuild HDF4 library (there is no need to rebuild GDAL if it is already compiled with HDF4 support). <p> <li> JPEG2000 support based on JasPer toolkit which can be accessed from the <a href="http://www.ece.uvic.ca/~mdadams/jasper/"> The JasPer Project Home Page</a>. <p> <p> JasPer itself is a bridge for working with several image file formats. Only JP2 and JPC parts of JasPer used in GDAL. <p> </ul> <p> <hr><address><small>Generated at Sat Dec 21 14:02:03 2002 for GDAL by <a href="http://www.stack.nl/~dimitri/doxygen/index.html"> <img src="doxygen.gif" alt="doxygen" align="middle" border=0 width=110 height=53></a>1.2.3-20001105 written by <a href="mailto:dimitri@stack.nl">Dimitri van Heesch</a>, © 1997-2000</small></address> </body> </html>
