[GRASS-user] Unable to load gdal library error

Daniel_Victoria · September 22, 2010, 12:36pm

Hi list,

I compiled Grass 6.5 svn from source in Ubuntu 9.10 and it was
apperently working OK. I then loaded a bunch of srtm tiles using
r.external but, when I tried to patch them with r.patch I recieved the
message: ERROR: Unable to load GDAL library. I also cannot display the
srtm tiles imported using r.external in the Grass Map. However, I can
iimport the srtm tiles using r.in.gdal and then raster display works
fine. My idea is to bring several SRTM tiles in grass using r.external
and then use r.patch. I was hopping not to use r.in.gdal in order to
save disk space...

Why is it that r.in.gdal works but r.external don't?

Thanks
daniel

Hamish · September 23, 2010, 3:36am

Daniel wrote:

I compiled Grass 6.5 svn from source in Ubuntu 9.10 and it was
apperently working OK. I then loaded a bunch of srtm tiles using
r.external but, when I tried to patch them with r.patch I recieved the
message: ERROR: Unable to load GDAL library. I also cannot display the
srtm tiles imported using r.external in the Grass Map.

no idea, but check that gdalinfo, gdalwarp, gdal_translate, etc still work.

However, I can iimport the srtm tiles using r.in.gdal and then raster
display works fine. My idea is to bring several SRTM tiles in grass
using r.external and then use r.patch. I was hopping not to use
r.in.gdal in order to save disk space...

GDAL comes with a nifty little app called "gdal_vrtmerge":
swig/python/samples/gdal_vrtmerge.py

if you feed it all your SRTM tiles, it will virtually patch them together,
and then you can use gdal tools or r.in.gdal on the virtual mosaic.

this is really great for running with "gdal2tiles" for an instant
OpenLayers browser of all the data.
swig/python/scripts/gdal2tiles.py

finally, if you put gdal_vrtmerge together with (a functioning..)
r.external, you hardly have to take up any more disk space than the
raw data files. Great for massive data caches where duplicates & disk
space is an issue. If disk I/O is a limiting factor, probably it's faster
to process too.

Hamish

Daniel_Victoria · September 24, 2010, 1:01am

On Thu, Sep 23, 2010 at 12:36 AM, Hamish <hamish_b@yahoo.com> wrote:

Daniel wrote:

I compiled Grass 6.5 svn from source in Ubuntu 9.10 and it was
apperently working OK. I then loaded a bunch of srtm tiles using
r.external but, when I tried to patch them with r.patch I recieved the
message: ERROR: Unable to load GDAL library. I also cannot display the
srtm tiles imported using r.external in the Grass Map.

no idea, but check that gdalinfo, gdalwarp, gdal_translate, etc still work.

It's strange cause I can use gdalinfo and gdal_translate on the SRTM
tif tiles and last night I patched them using gdal_merge.py. Also,
r.in.gdal works fine. And I can run r.info on the tiles imported using
r.external. But I can't display them or query the values (r.what also
gives ERROR: Unable to load GDAL library).

For the record, my GDAL configure line is: --with-gdal=/usr/bin/gdal-config \
I have GDAL 1.7.2, released 2010/04/23 which I believe I got from the
ubuntu-gis repositories

However, I can iimport the srtm tiles using r.in.gdal and then raster
display works fine. My idea is to bring several SRTM tiles in grass
using r.external and then use r.patch. I was hopping not to use
r.in.gdal in order to save disk space...

GDAL comes with a nifty little app called "gdal_vrtmerge":
swig/python/samples/gdal_vrtmerge.py

I was not aware of the vrtmerge function. Will give that a try, and
hope to identify what is wrong with r.external so I can reduce disk
space and speed things up. However, since I'll be running r.terraflow
on this huge SRTM image, would it be faster to import the image and
then run r.terraflow? Or use r.terraflow on a imaged linked using
r.external?

Cheers
Daniel

if you feed it all your SRTM tiles, it will virtually patch them together,
and then you can use gdal tools or r.in.gdal on the virtual mosaic.

this is really great for running with "gdal2tiles" for an instant
OpenLayers browser of all the data.
swig/python/scripts/gdal2tiles.py

finally, if you put gdal_vrtmerge together with (a functioning..)
r.external, you hardly have to take up any more disk space than the
raw data files. Great for massive data caches where duplicates & disk
space is an issue. If disk I/O is a limiting factor, probably it's faster
to process too.

Hamish

Hamish · September 24, 2010, 5:00am

Daniel wrote:

>> r.external [...]
>> ERROR: Unable to load GDAL library.

..

It's strange cause I can use gdalinfo and gdal_translate on the SRTM
tif tiles and last night I patched them using gdal_merge.py. Also,
r.in.gdal works fine. And I can run r.info on the tiles imported using
r.external. But I can't display them or query the values (r.what also
gives ERROR: Unable to load GDAL library).

try

ldd `which r.what`

and examine if the GDAL library versions are consistent with what you
think it should be using (`gdalinfo --version` and ldd `which gdalinfo`)

if gdal was upgraded after grass was built, grass may need to be rebuilt
against the new version of gdal..

However, since I'll be running r.terraflow on this huge SRTM image,

MMetz will suggest you try the new r.watershed too

would it be faster to import the image and then run r.terraflow?

probably.

Hamish

Daniel_Victoria · September 24, 2010, 12:29pm

Tried recompiling grass but that did not change anything. So I ran ldd
`which r.what` and it did not show any links to a gdal library... This
is what I got

GRASS 6.5.svn (br_wgs84):~ > ldd `which r.what`
  linux-gate.so.1 => (0x00f71000)
  libgrass_gis.so => /usr/local/grass-6.5.svn/lib/libgrass_gis.so (0x00a31000)
  libgrass_datetime.so =>
/usr/local/grass-6.5.svn/lib/libgrass_datetime.so (0x00c02000)
  libz.so.1 => /lib/libz.so.1 (0x002ca000)
  libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00681000)
  libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00d3d000)
  libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00ace000)
  /lib/ld-linux.so.2 (0x005a5000)
GRASS 6.5.svn (br_wgs84):~ >

Does this means that I messed up during compilation?

Cheers

Daniel

On Fri, Sep 24, 2010 at 2:00 AM, Hamish <hamish_b@yahoo.com> wrote:

Daniel wrote:

>> r.external [...]
>> ERROR: Unable to load GDAL library.

..

It's strange cause I can use gdalinfo and gdal_translate on the SRTM
tif tiles and last night I patched them using gdal_merge.py. Also,
r.in.gdal works fine. And I can run r.info on the tiles imported using
r.external. But I can't display them or query the values (r.what also
gives ERROR: Unable to load GDAL library).

try

ldd `which r.what`

and examine if the GDAL library versions are consistent with what you
think it should be using (`gdalinfo --version` and ldd `which gdalinfo`)

if gdal was upgraded after grass was built, grass may need to be rebuilt
against the new version of gdal..

However, since I'll be running r.terraflow on this huge SRTM image,

MMetz will suggest you try the new r.watershed too

would it be faster to import the image and then run r.terraflow?

probably.

Hamish

Hamish · September 25, 2010, 5:33am

Daniel wrote:

Tried recompiling grass but that did
not change anything. So I ran ldd
`which r.what` and it did not show any links to a gdal
library... This is what I got

GRASS 6.5.svn (br_wgs84):~ > ldd `which r.what`
linux-gate.so.1 =>
(0x00f71000)
libgrass_gis.so =>
/usr/local/grass-6.5.svn/lib/libgrass_gis.so (0x00a31000)
libgrass_datetime.so =>
/usr/local/grass-6.5.svn/lib/libgrass_datetime.so
(0x00c02000)
libz.so.1 => /lib/libz.so.1
(0x002ca000)
libm.so.6 =>
/lib/tls/i686/cmov/libm.so.6 (0x00681000)
libc.so.6 =>
/lib/tls/i686/cmov/libc.so.6 (0x00d3d000)
libdl.so.2 =>
/lib/tls/i686/cmov/libdl.so.2 (0x00ace000)
/lib/ld-linux.so.2 (0x005a5000)
GRASS 6.5.svn (br_wgs84):~ >

Does this means that I messed up during compilation?

no, just that a library calls gdal not the module. try:
ldd /usr/local/grass-6.5.svn/lib/libgrass_gis.so

Hamish

Glynn_Clements1 · September 25, 2010, 10:57am

Daniel Victoria wrote:

It's strange cause I can use gdalinfo and gdal_translate on the SRTM
tif tiles and last night I patched them using gdal_merge.py. Also,
r.in.gdal works fine. And I can run r.info on the tiles imported using
r.external. But I can't display them or query the values (r.what also
gives ERROR: Unable to load GDAL library).

That error message indicates a failure to load the GDAL library at run
time via dlopen(). r.in.gdal is linked against GDAL, and r.info
doesn't need access to the raster data. You will only get the error
from modules which attempt to access the raster data for a "linked"
map created with r.external.

The code which loads the library attempts to dlopen() each of
following names in turn:

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

If none of the attempts succeed, you get the above error.

The library must be listed in /etc/ld.so.cache (generated by ldconfig)
or in one of the directories in $LD_LIBRARY_PATH. Also, it must have
complete dependency information, and all of its dependencies must be
satisfied.

--
Glynn Clements <glynn@gclements.plus.com>

Daniel_Victoria · September 25, 2010, 7:20pm

On Sat, Sep 25, 2010 at 7:57 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Daniel Victoria wrote:

It's strange cause I can use gdalinfo and gdal_translate on the SRTM
tif tiles and last night I patched them using gdal_merge.py. Also,
r.in.gdal works fine. And I can run r.info on the tiles imported using
r.external. But I can't display them or query the values (r.what also
gives ERROR: Unable to load GDAL library).

That error message indicates a failure to load the GDAL library at run
time via dlopen(). r.in.gdal is linked against GDAL, and r.info
doesn't need access to the raster data. You will only get the error
from modules which attempt to access the raster data for a "linked"
map created with r.external.

The code which loads the library attempts to dlopen() each of
following names in turn:
   libgdal\.1\.1\.so
   gdal\.1\.0\.so
   gdal\.so\.1\.0
   libgdal\.so\.1
   libgdal\.so
If none of the attempts succeed, you get the above error.

The library must be listed in /etc/ld.so.cache (generated by ldconfig)
or in one of the directories in $LD_LIBRARY_PATH. Also, it must have
complete dependency information, and all of its dependencies must be
satisfied.

I guess it's a library naming problem then because what I have inside
ld.so.chache is:

daniel@xadrez:/etc$ sudo ldconfig -p | grep gdal
  libgdal1.7.0.so.1 (libc6) => /usr/lib/libgdal1.7.0.so.1
  libgdal1.7.0.so (libc6) => /usr/lib/libgdal1.7.0.so
  libgdal1.6.0.so.1 (libc6) => /usr/lib/libgdal1.6.0.so.1
daniel@xadrez:/etc$

Also, I don't have any of the lib names mentioned by Glynn in
/usr/lib, as you can see bellow.

daniel@xadrez:/usr/lib$ ls *gdal*
libgdal1.6.0.so.1 libgdal1.7.0.a libgdal1.7.0.so.1
libgdal1.6.0.so.1.13.3 libgdal1.7.0.so libgdal1.7.0.so.1.14.2

gdal16plugins:
gdal_GRASS.so ogr_GRASS.so

gdal17plugins:
gdal_GRASS.so ogr_GRASS.so

So, by linking libgdal.1.1.so to libgdal1.7.0.so everything came back
to normal... Well, sort of... Now, when I try r.what on the raster I
get...

WARNING: category support for [srtm_21_12] in mapset [PERMANENT] missing
ERROR: Unable to read category file of raster map <srtm_21_12> in
<PERMANENT>

For the record, this is part of the r.info output of the srtm tile:

Cheers
Daniel

Glynn Clements <glynn@gclements.plus.com>