[GRASS5] Using external PROJ with 5.3

Paul Kelly paul-grass at stjohnspoint.co.uk
Fri May 14 08:38:48 EDT 2004


Hello Radim

On Fri, 14 May 2004, Radim Blazek wrote:

> If I understand the situation well, I don't think that any external
> library should be distributed with GRASS. Say that somebody
> has GDAL 1.9 installed on his system:
> /usr/local/lib/libgdal.1.1.so
> /usr/local/bin/<gdal programs>
> his LD_LIBRARY_PATH is empty and it works well for him, then he installs
> GRASS with libgdal.1.1.so from GDAL 1.8.

It won't be 1.8 unless someone prepares a bad binary distribution; the 
release rules for GRASS say to use the latest GDAL CVS and I think it is a 
good idea to include a GDAL version that has been tried and tested to work 
with the version of GRASS Being distributed

> In GRAS shell, the (old) version of libgdal.1.1.so from GRASS will
> be used and all GDAL programs from /usr/local/bin/ will use wrong library
> from GRASS.

I also think it would be (fairly) intuitive to the user there to run the 
GDAL commands outside GRASS if he was getting bad results. More intuitive 
than the problem of installing gdal and proj libraries in /usr/local/lib 
but not updating LD_LIBRARY_PATH or /etc/ld.so.conf. Going by the 
experience with proj in 5.7 I would expect to get many 'bug' reports about 
like that and would like to try and cut down the workload on replying to 
them.

Of course I'm not saying that including GDAL and PROJ Libraries with GRASS 
is a perfect elegant solution. But I can't see anything really bad about 
it either. I am assuming of course that due to the way LD_LIBRARY_PATH is 
set, it is only possible for these libraries to be used if you are inside 
a GRASS session?

Reducing the amount of bug reports and simple questions about installing 
GDAL and PROJ is my main motivation in saying they should be included in 
the binary distributions.

Paul




More information about the grass-dev mailing list