[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