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