I'm stumped. Downloaded the libgdal* and libstdc++* tarball from Frank's
web site, put the files in $GISBASE/lib (/usr/local/grass5/lib), added that
path to /etc/ld.so.conf and ran /sbin/ldconfig. But, ...
When I run r.in.gdal within GRASS, I keep getting the error message that
it's unable to initialize the GDAL bridge. From within GRASS, 'echo
$LD_LIBRARY_PATH' shows /usr/local/grass5/lib.
What have I missed?
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Making environmentally-responsible mining happen.
Rich Shepard wrote:
I'm stumped. Downloaded the libgdal* and libstdc++* tarball from Frank's
web site, put the files in $GISBASE/lib (/usr/local/grass5/lib), added that
path to /etc/ld.so.conf and ran /sbin/ldconfig. But, ...
When I run r.in.gdal within GRASS, I keep getting the error message that
it's unable to initialize the GDAL bridge. From within GRASS, 'echo
$LD_LIBRARY_PATH' shows /usr/local/grass5/lib.
Note that r.in.gdal uses its own "home grown" mechanism for locating
the GDAL library. It looks for the library under the names
libgdal.1.1.so, gdal.1.0.so, gdal.so.1.0 and libgdal.so.1 (in that
order).
For each name, it tries (in order) $GISBASE/lib/<name>,
$GDAL_HOME/<name> then just <name>. The last one should use the
dynamic loader's standard lookup mechanism (i.e. $LD_LIBRARY_PATH then
/etc/ld.so.cache).
For each actual pathname, it calls dlopen(<name>, RTLD_LAZY) on the
pathname, then dlysym(<handle>, "GDALOpen").
Things that could go wrong include it not being in the right directory
(although both the first and third attempts should find it in your
case), not having the right filename, not defining GDALOpen (e.g.
because the name is "decorated"), or failing to load necessary
dependencies (e.g. my version requires the TIFF, JPEG, PNG and zlib
libraries, as well as libstdc++ and the libc, libm and libdl system
libraries).
--
Glynn Clements <glynn.clements@virgin.net>
On Wed, 25 Jul 2001, Glynn Clements wrote:
Things that could go wrong include it not being in the right directory
(although both the first and third attempts should find it in your case),
not having the right filename, not defining GDALOpen (e.g. because the
name is "decorated"), or failing to load necessary dependencies (e.g. my
version requires the TIFF, JPEG, PNG and zlib libraries, as well as
libstdc++ and the libc, libm and libdl system libraries).
Glynn,
Frank put me back on the tracks by checking the shared library
dependencies. gdal was built with glibc-2.2 and I have glibc-2.1.3
installed. Duh! So, I grabbed the 1.1.5b1 tarball and built it locally. Now
it runs.
I do, however, have a projection mis-match between the SDTS DEM file and
my project file. I'm not sure how to handle this now, but I'll be playing
with it this afternoon and see what I can learn.
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Making environmentally-responsible mining happen.