[Rd] Bundling system dependencies in binary packages
Prof Brian Ripley
ripley at stats.ox.ac.uk
Wed Dec 3 07:40:00 CET 2014
On 02/12/2014 18:34, Louis Aslett wrote:
> I've been hunting round for the accepted method of bundling system
> dependencies into binary packages.
> For example, there are some CRAN packages (e.g. gmp, RcppArmadillo,
> ...) which don't require the system dependencies be installed for the
> Windows and Mac binary builds. I understand that there are a very
> limited number of packages for which CRAN would do this, so as a first
> step I'm *not* asking how to get this on CRAN, but rather this
> highlights there must be a (fairly automated/easy) mechanism to
> achieve this. Is it as simple as statically linking? If so there's
Well, packages using just C++ headers (RcppArmadillo is one) do not have
libraries to link to.
But as far as possible the Windows and OS X binary packages are
statically linked. What is available to CRAN package builds is at
http://r.research.att.com/libs/ (and includes gmp).
> surely an automated way to trigger this without having to modify
> Makevars to produce the static linked packages?
> The Writing R Extensions manual section on binary packages doesn't
> mention this and I've tried extensive Googling without joy.
Nothing special is needed: the linkers use static linking if there is no
dynamic library available. So the external software is built with
configure options --enable-static --disable-shared . On OS X it also
has to be built with PIC flags (not the default for static libraries).
> So in a nut shell, I'm looking to bundle a binary version of GMP
> (https://gmplib.org) and FLINT (http://flintlib.org) into my package
> for Windows/Mac users who can't/won't compile the libraries and which
> I can distribute independently of CRAN, but without having to do so in
> a manual/hacky way by tweaking Makevars each time, or modifying the
> tgz/zip produced by R.
There are a few exceptions where dynamic linking is used on Windows, and
the configure scripts are used to install DLLs into the libs directory.
(RCurl is one, currently.) The main reason for not doing so is naming
conflicts for DLLs on Windows. For example, if you were to have a
gmp.dll and so did package gmp, the first loaded would win, even though
they might be different versions (and this was common for zlib1.dll).
> Hope I've been clear enough there.
> Any pointers much appreciated,
> R-devel at r-project.org mailing list
Brian D. Ripley, ripley at stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK
More information about the R-devel