[Proj] installing proj

[Glynn Clements]

Roger Oberholtzer wrote:

> > > I want to install Proj on my Linux machine.

> > > but when i run proj
> > > from the command line I get the following:
> > > 
> > > $ proj
> > > proj: error while loading shared libraries: libproj.so.0: cannot open shared
> > > object file: No such file or directory

> > export LD_LIBRARY_PATH=<path_to_the_dir_that_contains_libproj.so>
> 
> Better yet:
> 
> export LD_LIBRARY_PATH=<path_to_libproj.so_dir>:$LD_LIBRARY_PATH

Alternatively, add the directory to /etc/ld.so.conf, then run
ldconfig.

In general, ld.so.conf is preferable for making libraries "globally"
available, as:

1. It is more efficient. Any directories in $LD_LIBRARY_PATH are
checked every time an executable is run. If you have many such
directories, or those directories contain many files, this can result
in a performance hit.

2. When running any setuid or setgid executable, the loader removes
any LD_LIBRARY_PATH setting for security reasons. This may prevent
e.g. running a PROJ-based program in a separate xterm if xterm is
setuid/setgid.

One reason to use LD_LIBRARY_PATH is if you don't want to (or cannot)
make libraries available "globally", e.g. if you don't have root
privilege, or if you want to use an "unstable" version of a library
for a particular purpose but leave the rest of the system using a more
stable version.

Another reason is if you only need to make the libraries available in
a specific context. E.g. GRASS' startup script uses LD_LIBRARY_PATH to
make the GRASS libraries available during a GRASS session. As the
libraries rely upon some settings which won't normally be available,
they aren't much use outside of a GRASS session. But using
LD_LIBRARY_PATH meanst that we have to jump through some hoops so that
spawning programs in a separate xterm works when xterm is
setuid/setgid.

-- 
Glynn Clements <glynn at gclements.plus.com>