[Gdal-dev] GDAL nix build configuration

David Friberg dfriberg23 at gmail.com
Fri Nov 17 19:46:56 EST 2006


I would like to request a change to the rpath (hard-coded library
search path) used in the shared libraries produced by the GDAL build
system.  The rpath currently used is problematic for us because it
contains the major version number, but not the revision number or age
(e.g. /usr/local/lib/libgdal.1.dylib).  This search path is also
propagated to every executable and shared library that links to GDAL.
An incompatible version of GDAL may exist in /usr/local/lib, so the
dynamic linker will use that if present.  Since we do not want to
install GDAL to /usr/local/lib, overwriting what's there, our
executables fail to work due to the incompatible libgdal.

There are two solutions I can think of for this issue:

1) change the rpath to include the full version string.

This was my solution to the problem; I hack the libtool that came with
GDAL as follows:

soname_spec="\${libname}\${release}\${major}\$shared_ext"

Change both lines that look like this to:

soname_spec="\${libname}\${release}\${versuffix}\$shared_ext"

That forces the issue of having the full version number in the rpath.
If it doesn't find the specified library, the dynamic linker will
continue to the next search path until it finds the correct version.

2) don't use an rpath

I haven't figured out how to do this.  Probably could hack libtool.

Or maybe there's a much better way to do these things?

David Friberg
MicroImages, Inc.



More information about the Gdal-dev mailing list