[GRASSLIST:1135] Re: Fwd: Re: gdal problem
Keith J. Forbes
listsemail at gmx.net
Mon Sep 8 11:03:09 EDT 2003
On Thursday 28 August 2003 04:20 pm, Frank Warmerdam wrote:
> Keith J. Forbes wrote:
> > I assume the fact that gdalinfo already works means that recompiling
> > grass --with-gdal will not help, right? For the record, I have never
> > before used the r.in.gdal module. I am sending this directly to you so
> > that I do not offend the sender of the email.
>
> Keith,
>
> If gdalinfo works, but r.in.gdal fails then one fairly likely possibility
> is that the problem is with the way that r.in.gdal calls libgdal. The
> default mechanism is a manual loading of the shared library by the
> program code (my so called "bridging" approach). This may well be
> broken now days and compiling --with-gdal will force r.in.gdal to actually
> link against libgdal directly avoiding a bunch of possible errors.
>
> So, Paul may well be right, and if so I would appreciate hearing about it.
> The other problem I saw but never completely verified was a user's whose
> location was corrupt in some way, and r.in.gdal would core dump quite
> early in the run. If that is the issue, you might want to try starting
> a new location or something like that.
>
> By the way, since gdalinfo works, I would suggest you now try
> gdal_translate:
>
> gdal_translate /path/to/directory out.tif
>
> If that works then the problem is r.in.gdal specific for sure, and should
> be submitted via the GRASS bug system if you can't work around it.
> Unfortunately, it also means it is substantially less likely that I will
> look into the problem since I don't have a working GRASS build at this
> time.
>
>
> Best regards,
Hi Frank.
I successfully recompiled grass as follows:
./configure --with-postgres-includes=/usr/local/pgsql/include/
--with-gdal=/usr/local/share/gdal --with-postgres-libs=/usr/local/pgsql/lib
compilation worked but I continue to get the segmentation fault when i try
r.in.gdal. part of the configure script output says:
----snip--------
checking if we should build directly against GDAL... no
----snip-----
did i do something incorrectly ???
should I have specified /usr/local/share/gdal OR /usr/local/lib
(the respective files/directories follow)
GRASS:/usr/local/share > ls -al gdal
total 1028
drwxr-xr-x 2 root root 4096 Aug 28 15:11 .
drwxr-xr-x 15 root root 4096 Jul 22 17:20 ..
-rw-r--r-- 1 root root 73770 Jun 6 13:20 datum.csv
-rw-r--r-- 1 root root 233102 Aug 28 15:11 ecw_cs.dat
-rw-r--r-- 1 root root 10735 Aug 28 15:11 ellipsoid.csv
-rw-r--r-- 1 root root 23873 Aug 28 15:11 gcs.csv
-rw-r--r-- 1 root root 78706 Aug 28 15:11 gdal_datum.csv
-rw-r--r-- 1 root root 533 Aug 28 15:11 gdalicon.png
-rw-r--r-- 1 root root 332781 Aug 28 15:11 pcs.csv
-rw-r--r-- 1 root root 1599 Aug 28 15:11 prime_meridian.csv
-rw-r--r-- 1 root root 139098 Aug 28 15:11 projop_wparm.csv
-rw-r--r-- 1 root root 7254 Aug 28 15:11 s57attributes.csv
-rw-r--r-- 1 root root 20885 Aug 28 15:11 s57expectedinput.csv
-rw-r--r-- 1 root root 31211 Aug 28 15:11 s57objectclasses.csv
-rw-r--r-- 1 root root 9216 Aug 28 15:11 seed_2d.dgn
-rw-r--r-- 1 root root 2048 Aug 28 15:11 seed_3d.dgn
-rw-r--r-- 1 root root 10315 Aug 28 15:11 stateplane.csv
-rw-r--r-- 1 root root 15266 Aug 28 15:11 unit_of_measure.csv
.............................................
in /usr/local/lib I have:
-rw-r--r-- 1 root root 3019037 Aug 28 15:11 libgdal.1.1.so
-rw-r--r-- 1 root root 4339004 Aug 28 15:10 libgdal.a
.............................................
WHEN I TRIED R.IN.GDAL
GRASS:~/grass5/src/grass5.0.2 > r.in.gdal
input=~/grass5/datasrc/hadrm/a2c_con/etp/ output=test
Segmentation fault
Thanks,
Keith
-----------------
--
k|J|f
More information about the grass-user
mailing list