[GRASSLIST:2179] Re: r.in.gdal : Unresolvable problems?

[Glynn Clements]

Ben Logan wrote:

> > > This morning I ran 'find' from the root of my filesystem and searched
> > > for anything named gdal* libgdal* or ogr*.  I removed everything (gdal
> > > related) that turned up, removed the grass installation and sources
> > > and removed the gdal sources.  I then compiled gdal-1.1.9, and grass
> > > 5.0.3 using --with-gdal (and also --without-fftw, but I'm assuming
> > > that shouldn't affect it).  I had the same problem as before.
> > 
> > One comment: when building GDAL for use with GRASS, it may help to use
> > the --without-grass configure switch.
> 
> Thanks for the suggestion.  I tried doing as you said.  First, I
> totally uninstalled the gdal libs (and includes) from my system and
> then recompiled with --without-grass.  Then I tried running r.in.gdal
> again (without recompiling grass).  It still segfaulted, so I removed
> my grass installation and recompiled it (using --with-gdal).  Still
> failed.  One thing I noted was that there are two versions of
> r.in.gdal--one in /usr/local/grass5/etc/bin/cmd and one in
> /usr/local/grass5/bin.  They differ (the one under etc is quite a bit
> larger), and the one under bin is the one which gets run under GRASS,
> but I tried running the other and it failed too.

Almost everything in the bin directory is a (hard) link to
etc/front.end. The "real" programs live in etc/bin/cmd and
etc/bin/inter.

front.end simply determines whether to run the "cmd" or "inter"
version, depending upon which exists, and whether any arguments were
given. This allows a module to have separate command-line and
interactive versions.

> I'm starting to see red right now, so I think I'll give it a rest for
> today. :-)  I have installed Knoppix on my HD so I can remaster it, so
> tomorrow I will try compiling grass and gdal under Knoppix.  That's a
> brand spankin' knew development environment, so there's no possibility
> that there are any old libs lying around etc.  If that doesn't work,
> I'll really be lost....something tells me it isn't going to work
> either.  If someone can help me make sense of it, I'll run gdb on
> r.in.gdal.  I don't know much C/C++, so I'll need some help.

Some other thing which might make a difference are linking r.in.gdal
with g++ instead of gcc, using an earlier version of GDAL, and
disabling optimisation.

r.in.gdal itself is a fairly simple program. OTOH, the GDAL library is
complex, and is written in C++ (which greatly increases the potential
for problems). Consequently, any problems are far more likely to be in
GDAL than in r.in.gdal (provided that you are using --with-gdal; the
dynamic loading option can be problematic).

As for debugging:

1. Run gdb on /usr/local/grass5/etc/bin/cmd/r.in.gdal rather than just
r.in.gdal, as the latter is just the front.end program.

2. Make sure that both r.in.gdal and the GDAL library were built with
debug info (-g), and preferably without optimisation. This can usually
be achieved by using "CFLAGS=-g ./configure ..." when configuring the
package in question (the default is "-g -O2", which enables
optimisation; this can complicate debugging, as the resulting code
often bears little resemblance to the source code).

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