R devel - Sep 2016 - Building R under Linux - library dependencies

Hello and apologies if this doesn't belong here.

I'm trying to build a "portable" version of R -
"portable" means that it could be easily moved to another location or
machine simply by copying it. However, I encountered a problem when running it
elsewhere: it seems that versions of dynamic libraries used by R are fixed and
set at the build time; when that instance of R is run on a system with a
different version of certain library (e.g. libicuuc.so.52 instead of
libicuuc.so.48), it can't find it and quits.
> bin/exec/R: error while loading shared libraries: libicuuc.so.48: cannot
open shared object file: No such file or directory
Is there a way to overcome this problem? Precompiled versions of R can be
installed on various system configurations, so I guess that there should be a
way to compile it in a version-agnostic manner.

Best regards,
Pawel

On 7 September 2016 at 17:27, Pawe? Pi?tkowski wrote:
| Hello and apologies if this doesn't belong here.
| 
| I'm trying to build a "portable" version of R -
"portable" means that it could be easily moved to another location or
machine simply by copying it. However, I encountered a problem when running it
elsewhere: it seems that versions of dynamic libraries used by R are fixed and
set at the build time; when that instance of R is run on a system with a
different version of certain library (e.g. libicuuc.so.52 instead of
libicuuc.so.48), it can't find it and quits.
| 
| > bin/exec/R: error while loading shared libraries: libicuuc.so.48: cannot
open shared object file: No such file or directory
| 
| Is there a way to overcome this problem? Precompiled versions of R can be
installed on various system configurations, so I guess that there should be a
way to compile it in a version-agnostic manner.

Yes, for example by

  -- using a Docker container which is portable across OSs (!!) and versions

  -- relying on package management which is what every Linux distro does

Otherwise you are trying to reinvent a systems-level wheel in application
space. I suspect that won't end well.

Dirk


PS For the latter point, our .deb based R package currently shows this:

Package: r-base-core
Source: r-base
Priority: optional
Section: gnu-r
Installed-Size: 33845
Maintainer: Dirk Eddelbuettel <edd at debian.org>
Architecture: amd64
Version: 3.3.1-1.xenial.0
Recommends: r-recommended, r-base-dev, r-doc-html
Replaces: r-base (<= 1.4.1-1), r-base-latex (<= 2.9.2-4), r-cran-rcompgen
(<= 0.1-17-1), r-gnome (<= 2.3.1), r-recommended (<< 1.9.0)
Suggests: ess, r-doc-info | r-doc-pdf, r-mathlib, r-base-html
Provides: r-api-3, r-base-latex, r-cran-rcompgen, r-gnome
Depends: zip, unzip, libpaper-utils, xdg-utils, libblas3 | libblas.so.3,
libbz2-1.0, libc6 (>= 2.23), libcairo2 (>= 1.6.0), libcurl3 (>=
7.28.0), libglib2.0-0 (>= 2.12.0), libgomp1 (>= 4.9), libjpeg8 (>= 8c),
liblapack3 | liblapack.so.3, liblzma5 (>= 5.1.1alpha+20120614),
libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpcre3,
libpng12-0 (>= 1.2.13-4), libreadline6 (>= 6.0), libtcl8.6 (>= 8.6.0),
libtiff5 (>= 4.0.3), libtk8.6 (>= 8.6.0), libx11-6, libxt6, zlib1g (>=
1:1.1.4), ucf (>= 3.0), ca-certificates
Conflicts: r-base-latex, r-cran-rcompgen, r-gnome
Filename: pool/main/r/r-base/r-base-core_3.3.1-1.xenial.0_amd64.deb
Size: 20939808
MD5sum: a983ccafe969cc4d8a631036478ac1c2
SHA1: 1fd9991b2577bf18074cd0a7e8017a98d4efef13
SHA256: 9a0cc3d5edf6b628d854a075731f30b460ea9ff465327693eb2d92b59ac01901
Description-en: GNU R core of statistical computation and graphics system
[...]

Note the detailed and fine-grained breakdown of library dependencies.


-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

> | Is there a way to overcome this problem? Precompiled versions of R can be
installed on various system configurations, so I guess that there should be a
way to compile it in a version-agnostic manner.
> 
> Yes, for example by
> 
>   -- using a Docker container which is portable across OSs (!!) and
versions
Docker R containers are north of 250 MB. I have checked experimentally that you
can trim R down to 16 MB (!) and you'll still be able to execute it (though
with warnings). That *is* quite a difference, especially when deploying small
applications.
>   -- relying on package management which is what every Linux distro does
> 
> (...)
> 
> PS For the latter point, our .deb based R package currently shows this:
> 
> (...)
> 
> Depends: zip, unzip, libpaper-utils, xdg-utils, libblas3 | libblas.so.3,
libbz2-1.0, libc6 (>= 2.23), libcairo2 (>= 1.6.0), libcurl3 (>=
7.28.0), libglib2.0-0 (>= 2.12.0), libgomp1 (>= 4.9), libjpeg8 (>= 8c),
liblapack3 | liblapack.so.3, liblzma5 (>= 5.1.1alpha+20120614),
libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpcre3,
libpng12-0 (>= 1.2.13-4), libreadline6 (>= 6.0), libtcl8.6 (>= 8.6.0),
libtiff5 (>= 4.0.3), libtk8.6 (>= 8.6.0), libx11-6, libxt6, zlib1g (>=
1:1.1.4), ucf (>= 3.0), ca-certificates
Sure, package dependencies would be great as well - at least you'd be sure
that users of, say, Debian-based distros will be able to run this portable R, as
long as they've installed the required libraries. But notice that in your
example package versions equal *or greater* than listed are required - so if
someone has upgraded their system, they still will be able to run that R. With a
version built from source you need *exactly* the same version as on the machine
where R was compiled. Hence my question: how come the precompiled distribution
of R has "less strict" library requirements than manually compiled
versions?

Best,
Pawel