Hi,
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. Does anyone
know the correct ifdef for unix?
Markus
On Mon, Nov 19, 2001 at 07:52:11PM +0100, Markus Neteler wrote:
Hi,
I have found that r.in.gdal ignores the LD_LIBRARY_PATH
settings. The reason is that insrc/raster/r.in.gdal/gdalbridge.c
#ifdef __unix__is used which obviously doesn't exists. Does anyone
know the correct ifdef for unix?
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.
Markus
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@virgin.net>