[GRASS5] Re: Current GDAL problem

Glynn Clements glynn.clements at virgin.net
Tue Apr 17 10:54:38 EDT 2001


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 at virgin.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list