[GRASSLIST:2498] r.in.gdal and libgdal.1.1.dylib

GRASS GRASS user
,
1

Hi

I tried to import a raster file (w001001.adf, 358 MB), which is in the directory 'codem1nw'. There must be some problems with the libgdal.1.1.dylib. Here is some output:

GRASS 5.0.2 > r.in.gdal in=codem1nw out=codem1nw.r
dyld: r.in.gdal Undefined symbols:
r.in.gdal undefined reference to _deflateInit_ expected to be defined in /usr/local/lib/libgdal.1.1.dylib
Trace/BPT trap

GRASS 5.0.2 > gdalinfo --version
GDAL 1.1.9.0, released 2003/06/27

GRASS 5.0.2 > gdalinfo codem1nw
[I received some reasonable output, no error messages.]

I work on Mac OS X (10.3.2).

Thanks for your help

Christof

2

It seems to be the same issue as discussed in list message # 2491 (quoted below). For dealing with a png file, I managed to get rid of the error by turning on the flags to use the internal tiff/jpeg/png libraries when compiling GDAL. But I guess that won't help you here. From Glynn's message, I guess that you should ensure that r.in.gdal was compiled AFTER your last GDAL lib update, but if that is already the case, there's an OS X linker issue we need to figure out.

Ian Macmillan wrote:

... Now my problem is that I can't actually
import the DEM into grass. Here is the error message I get when I run
r.in.gdal (it is similar to an error message already described, except I can't
get the file read in at all).
r.in.gdal undefined reference to _deflateInit_ expected to be defined in
/usr/local/lib/libgdal.1.1.dylib
Trace/BPT trap

Any ideas?

To which Glynn Clements wrote:

Ideas, yes; solution, no :frowning:

deflateInit is a zlib function. GDAL itself doesn't appear to use at
(at least, 1.1.3 doesn't), but some of the formats which it supports
do (notably PNG).

This might be a MacOSX linker/loader issue; the MacOSX loader appears
to be more strict than typical Unix loaders.

OTOH, it might be that the updated GDAL library was built slightly
differently to the old version, such that r.in.gdal would need to be
re-compiled.

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

On Feb 6, 2004, at 14:09, Christof Bigler wrote:

Hi

I tried to import a raster file (w001001.adf, 358 MB), which is in the directory 'codem1nw'. There must be some problems with the libgdal.1.1.dylib. Here is some output:

GRASS 5.0.2 > r.in.gdal in=codem1nw out=codem1nw.r
dyld: r.in.gdal Undefined symbols:
r.in.gdal undefined reference to _deflateInit_ expected to be defined in /usr/local/lib/libgdal.1.1.dylib
Trace/BPT trap

----
Scott Mitchell, Assistant Professor, Carleton University
Department of Geography & Environmental Studies, Loeb A209
Mailing: Loeb B349, 1125 Colonel By Dr., Ottawa, ON K1S 5B6 Canada
1-613-520-2600 x2695 Fax: 613-520-4301 Scott_Mitchell@carleton.ca

3

The import works. Apparently, the problem was the missing libgdal.1.1.dylib in /usr/local/lib. I had a higher libgdal.1.1.9.dylib version which had been installed with the GRASS binary distribution for OS X. I installed then the libgdal.1.1.dylib from http://gdal.velocet.ca/projects/grass.

Another thing: Is it possible to change the man pages for r.in.gdal? It took me literally hours to find out that the input name should be the directory and not the file itself. I found this information in a mail to the list from, I think, 2001, and also in the Open Source GIS book from Neteler & Mitasova.

Thanks
Christof

On 06.02.2004, at 12:09, Christof Bigler wrote:

Hi

I tried to import a raster file (w001001.adf, 358 MB), which is in the directory 'codem1nw'. There must be some problems with the libgdal.1.1.dylib. Here is some output:

GRASS 5.0.2 > r.in.gdal in=codem1nw out=codem1nw.r
dyld: r.in.gdal Undefined symbols:
r.in.gdal undefined reference to _deflateInit_ expected to be defined in /usr/local/lib/libgdal.1.1.dylib
Trace/BPT trap

GRASS 5.0.2 > gdalinfo --version
GDAL 1.1.9.0, released 2003/06/27

GRASS 5.0.2 > gdalinfo codem1nw
[I received some reasonable output, no error messages.]

I work on Mac OS X (10.3.2).

Thanks for your help

Christof

4

Hello
On Sun, 8 Feb 2004, Christof Bigler wrote:

The import works. Apparently, the problem was the missing
libgdal.1.1.dylib in /usr/local/lib. I had a higher libgdal.1.1.9.dylib
version which had been installed with the GRASS binary distribution for
OS X. I installed then the libgdal.1.1.dylib from
http://gdal.velocet.ca/projects/grass.

Another thing: Is it possible to change the man pages for r.in.gdal? It
took me literally hours to find out that the input name should be the
directory and not the file itself. I found this information in a mail
to the list from, I think, 2001, and also in the Open Source GIS book
from Neteler & Mitasova.

Are you saying that the bare filename worked with gdalinfo but not r.in.gdal?
If so, that is probably because gdalinfo is using the latest gdal library
which perhaps has that bug fixed, but because you downloaded a really old
version of libgdal to use with r.in.gdal, the bug was not fixed in that
version? (perhaps).

I have a feeling there is much more to this situation than meets the eye.
Where did you get your OSX GRASS binary distribtion from? Perhaps it had
some specially hacked gdalbridge code that was specifically looking for
the filename libgdal.1.1.dylib? Normally it only looks for libgdal.1.1.so
so would fail on OSX, which is a good thing because you need to compile
GRASS with the --with-gdal option anyway (avoiding use of the gdalbridge
code) if you want to use the most up-to-date gdal libraries.

But in your case you were content to use 1.1.4 as indicated on Frank's
download page so it was OK. Did simply renaming the libgdal.1.1.9.dylib to
libgdal.1.1.dylib not work? (I suspect it might have started to work
byt lead to a segmentation fault from r.in.gdal.)

The simple answer to most of the GRASS/GDAL problems is to install GDAL
first and then compile GRASS using the --with-gdal configure option.
Because the problem appears to be so complicated there are lots of other
obscure and quite random solutions that 'sort of' work, as you have
discovered.

I hope these thoughts might shed a little more light on the problem but it
isn't very important.

Paul K

5

On Sun, Feb 08, 2004 at 10:58:06AM -0700, Christof Bigler wrote:

The import works. Apparently, the problem was the missing
libgdal.1.1.dylib in /usr/local/lib. I had a higher libgdal.1.1.9.dylib
version which had been installed with the GRASS binary distribution for
OS X. I installed then the libgdal.1.1.dylib from
http://gdal.velocet.ca/projects/grass.

Another thing: Is it possible to change the man pages for r.in.gdal? It
took me literally hours to find out that the input name should be the
directory and not the file itself. I found this information in a mail
to the list from, I think, 2001, and also in the Open Source GIS book
from Neteler & Mitasova.

Christof,

in GDAL-CVS also file names work (bugfix a few days ago).
A trick for your GDAL version:

Try
./filename
instead of
filename
or, as you found out, the directory name.

So for the next GDAL release it will be solved. I suggest
to keep the man page as-is.

Markus

Thanks
Christof

On 06.02.2004, at 12:09, Christof Bigler wrote:

>Hi
>
>I tried to import a raster file (w001001.adf, 358 MB), which is in the
>directory 'codem1nw'. There must be some problems with the
>libgdal.1.1.dylib. Here is some output:
>
>GRASS 5.0.2 > r.in.gdal in=codem1nw out=codem1nw.r
>dyld: r.in.gdal Undefined symbols:
>r.in.gdal undefined reference to _deflateInit_ expected to be defined
>in /usr/local/lib/libgdal.1.1.dylib
>Trace/BPT trap
>
>GRASS 5.0.2 > gdalinfo --version
>GDAL 1.1.9.0, released 2003/06/27
>
>GRASS 5.0.2 > gdalinfo codem1nw
>[I received some reasonable output, no error messages.]
>
>I work on Mac OS X (10.3.2).
>
>Thanks for your help
>
>Christof
>

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy