[R-sig-Geo] RGDAL installation fail after yum upgrade

[Roger Bivand]

On Fri, 21 Sep 2018, Rich Shepard wrote:

> On Fri, 21 Sep 2018, David.GIOVANNINI using ext.ec.europa.eu wrote:
>
>>  I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems
>>  that the minimun required version has been satisfied. But on the system I
>>  have two version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the
>>  version v4.9.1 ( /usr/local/bin/proj ).
>
> David,
>
>  This is the cause of many problems: two different versions of software on
> the same host.
>
>>  So can I force the use of the new version of PROJ with some parameters
>>  during the installation of RGDAL?
>
>  Take a look at your $PATH; it's likely that /usr/local/bin/ is checked
> before usr/bin/. And different applications using, e.g., proj4, may look for
> it in either place. This means that one application finds the 4.9.1 version
> while another application finds the 4.8.0 version.

Rich: thanks - having multiple versions is indeed a challenge on platforms 
where R uses dynamically loaded libraries. On Windows and MacOS, most CRAN 
packages with external dependencies are built with static linking (the 
*old* way). However, executables are on the PATH, but dynamically loaded 
libraries - shared objects - are on LD_LIBRARY_PATH. Try:

echo $LD_LIBRARY_PATH

at the shell prompt, then inside R:

Sys.getenv("LD_LIBRARY_PATH")

and you'll see that R may have made modifications on startup. A typical 
trap is also forgetting to run /sbin/ldconfig -v as root after installing 
software in /usr/local/lib (and adding /usr/local/lib to a file in 
/etc/ld.so.conf.d) so that the shared objects are visible.

The easier route is to have just one version of external software 
installed where R can see it; it is harder but possibly on a cluster 
necessary to modify LD_LIBRARY_PATH locally and consistently. Also look at 
closed sf issues on github; there we stepped back from messing with 
LD_LIBRARY_PATH on a general basis.

Hope this helps,

Roger


>
>  I recommend that you put all core binaries in /usr/bin (which means moving
> 4.9.1 from /usr/local/bin/ to /usr/bin/ and keeping in the latter only
> software developed locally.
>
>  My network runs Slackware so I don't know how difficult it might be for
> you to re-organize your CentOS installations, but making the time to do this
> will make life easier for you.
>
> Best regards,
>
> Rich
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo using r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand using nhh.no
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en