[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