mberglund wrote:
I'm walking through glass on this one guys...
I have tried for the better part of 24hours to get GDAL to compile _and_
work with grass.
Not only do I need it for work, but I can't see how you can trust my
binaries if r.in.gdal fails routinely.
This is the latest cvs version of GDAL (1.1.5) and grass release candidate
5_0_0.
I get a consistent "ERROR: Unable to initialize GDAL bridge (check
libgdal installation)." from grass AND the bridge_test in GDAL fails
with a similar message. I was able to get a real result only once, (after
at least one hundred failures).
The system is suse 7.1, I have not installed anything exotic so I can't
see how the system might be affecting this issue.
If anyone has any idea on what I can check to deal with this, I would
r.in.gdal isn't directly linked against the GDAL library; instead, it
does a run-time link using dlopen()[1]. It looks for the library under
the following names:
libgdal.1.1.so
gdal.1.0.so
gdal.so.1.0
libgdal.so.1
For each of the above names, it looks for:
$GISBASE/lib/<name>
$GDAL_HOME/<name>
<name>
The last of these should (on Linux, at least) cause the library to be
looked for in the usual places (ld.so.cache, $LD_LIBRARY_PATH).
For each filename/directory combination, it queries the symbol
"GDALOpen" from the specified file.
So, the main things to check are that the library exists under one of
the above names, and that either:
a) it's in a directory listed in /etc/ld.so.conf, and "ldconfig" has
been run since it was put there, or
b) it's in a directory listed in $LD_LIBRARY_PATH, or
c) it's in $GISBASE/lib.
I wouldn't recommend using $GDAL_HOME; it just results in one more
thing for users to deal with (see the thread on "$PAGER").
[1] Furthermore, it calls dlopen() at least 69 times; once for each
function it wishes to use. It's actually 68+N times, where N is the
number of attempts at finding the library (max 12).
Does anyone mind if I re-write gdalbridge.c and gbgetsymbol.c so that
dlopen/LoadLibrary and dlsym/GetProcAddress are separate functions?
Or, better still, can't we just link directly against libgdal?
--
Glynn Clements <glynn.clements@virgin.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'