[GRASS5] r.in.gdal: gdalbridge bug

[Glynn Clements]

Markus Neteler wrote:

> > I have found that r.in.gdal ignores the LD_LIBRARY_PATH
> > settings. The reason is that in
> > 
> > src/raster/r.in.gdal/gdalbridge.c
> > #ifdef __unix__
> > 
> > is used which obviously doesn't exists.

It's defined by the preprocessor:

	$ echo > foo.c
	$ gcc -E -dM foo.c | fgrep unix
	#define __unix 1 
	#define __unix__ 1 
	#define unix 1 

> A follow up:
> Perhaps the LD_LIBRARY_PATH is caught elsewhere. However,
> r.in.gdal is currently ignoring the LD_LIBRARY_PATH 
> settings from the current GRASS session which makes it
> difficult to run different GDAL implementations.

AFAIK, it isn't ignoring it, but it's only used if the GDAL library
can't be found in $GISBASE/lib or $GDAL_HOME.

For each of the names:

	libgdal.1.1.so
	gdal.1.0.so
	gdal.so.1.0
	libgdal.so.1

gdalbridge.c calls dlopen() on:

	$GISBASE/lib/<name>
	$GDAL_HOME/<name>
	<name>

The last of these will look for the library using the same mechanism
as used by ld-linux.so; i.e. first search all directories in
$LD_LIBRARY_PATH, then look for an entry in /etc/ld.so.cache.

Note: using the configure switch "--with-gdal" should bypass
gdalbridge.c altogether; libgdal will just be linked in as with any
other shared library.

-- 
Glynn Clements <glynn.clements at virgin.net>