I have been struggling to get python setup to do some image processing, so I really need the http://www.gdal.org/ GDAL libraries installed on CentOS 6.5. I want to install the package in a local folder (maybe /workspace/GDAL) without root access. When I try to build from source, it seems CentOS is missing a bunch of libraries.

I will be using it for opening HDF4, HDF4-EOS files, and have a local installation of the HDF4/HDF5 libraries (say /workspace/HDF).

If I can install a binary without root, is there a way to point GDAL to these libraries?


Trying to build from source without root access is near impossible on CentOS. I have figured out that really the only practical way to solve this issue is using a conda package (for the Anaconda python distribution) built by Jose

The solution is to run this on a fresh install of Anaconda (step three being the important one): conda update conda conda update anaconda conda install -c https://conda.binstar.org/jgomezdans gdal=1.11.0

It appears without root access, the best option is the Anaconda package manager. This way, it comes with HDF4/HDF5/GEOS/etc everything needed to do geospatial analysis.


GDAL itself can certainly be built and used/installed without root access on most *nix type systems.

In these cases, I usually create a file structure to contain both the final GDAL build itself and all of its dependencies that the host OS doesn't already have. But, you could have them in separate folders as well as long as you have your path, LD_CONFIG, etc. setup properly.

You'll have to point the GDAL build system to look at that structure, which can normally be accomplished by supplying the appropriate --with-<package>=</pkg/directory> style configure parameters.

Run ./configure --help in the source directory to get a (long) list of those parameters. Getting everything setup will likely be a bit iterative.

Assuming you have built/obtained all of your dependencies: run ./configure, look at what fails, run again with the appropriate --with-<x> parameter, then something different will fail, add another --with- parameter, etc. until the configuration finishes. And then, you may have to add additional parameters to get everything enabled that you need.

  • Thank you. I will give that a try. What do you mean have your path, LD_CONFIG, etc. setup properly? Like, setenv LD_CONFIG '/workspace/HDF' something like that? Aug 15 '14 at 14:30
  • @jakebrinkmann I'm not familiar with the specifics of CentOS, but it should be along those lines. Basically, you need to tell the system that there are libraries in a non-standard location that binaries can load. You'll also have to have PATH setup properly for some scripts to work and there are some other GDAL specific environment variables for its data (CRS/projection). Aug 15 '14 at 14:34
  • 1
    I am trying to follow these instructions which I believe is similar to what you suggest. Wish there was a way to use yum without sudo for this Aug 15 '14 at 15:11

@Evil Genius' answer shows how a program is compiled and thus expects to find compiled information in a certain location. Since you say that you have the HDF libraries in /workspace/HDF, then you can try to set GDAL_DRIVER_PATH: export GDAL_DRIVER_PATH=/workspace/HDF:${GDAL_DRIVER_PATH}. Note that I put your proposed driver first in the path variable. The problem that you still may face is that your driver library may be compiled with incompatible configuration and entry points compared to what your existing gdal suite was compiled with. The other main gdal variables to work about are GDAL_DATA, GDAL_DRIVER_PATH, PROJ_LIB, and PATH. There are a gazillion more runtime variables listed on the gdal site.

Ummm...can you build a case to have your system admin help you with the root and missing package issues? After all they are there to help meet your project needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.