     [file macros.texi not included]

[$Revision: 6158 $]

Preamble
********

Using static libraries when linking packages is pretty much essential on Windows and macOS, mainly because loading dynamic libraries from non-system location is intentionally difficult on macOS and not simple on Windows (and how to do so has changed over the years). Further, binary packages are built by different people at different times and there would need to be careful version control of dynamic libraries. With static linking, each package is ensured to use the library routines available when it was linked, prior to distribution.

Many of the static libraries provided by MXE (as part of rtools) or via Simon Urbanek's `recipes' at https://mac.r-project.org/bin/ are projects which are commonly regarded as system libraries on Linux and FreeBSD systems and dynamically linked from system locations.

Issues
******

One drawback of using static libraries is code duplication and hence size of an installed library tree.  But end users tend not to have thousands of packages installed, and few of the static libraries are large. Those which are large are used by few packages -- e.g. ICU is ca 35MB but used only by two packages (one of which uses only a tiny part of it) and libQuantLib by one.

Using dynamic libraries allows these to be updated independently of the installed packages, for example if a vulnerability is found -- packages using static linking would need to be reinstalled (and users would need to know they need to reinstall them).

The main issues relate to licensing.  External libraries will almost always (but not always) have licences, and care is needed to ensure that these are compatible with the package's declared licence.  CRAN requires a single licence, but some library projects seem to believe it is possible to licence each source file so multiple licences will apply to a single library and all need to be complied with unless it is known precisely which parts will be linked into a package's DSO/DLL.  What forms of linking are allowed by certain licences and if there is a distinction made for 'system' libraries can be unclear or controversial. Some GPL-ed libraries have `linking exceptions' (e.g., https://en.wikipedia.org/wiki/GPL_linking_exception).

The more pervasive licensing issue are those licences which require copyright information or their whole licence to be included in any redistribution, often explicitly singling out binary distribution.  R itself meets these requirements through its doc/COPYRIGHTS and src/gnuwin32/COPURIGHTS.win files.  Keeping those up-to-date is tedious, as external software does change its licence(s).

Recursive dependencies
**********************

Static linking means that recursive dependencies need to be handled explicitly, often via pkg-config --static --libs.  And (L)GPL-ed libraries can depend on others with a BSD, Apache or other licence with redistribution requirements.  For example, quite a lot of libraries depend directly or indirectly on libtiff which requires redistribution of its (non-BSD) licence and libtiff has a large set of optional dependencies, some such as webp have BSD-style licences.  Such chains of dependence can result in a requirement to redistribute a dozen or more licences (for example for users of libgdal which optionally links to many other packages, some of which like libcurl and libtiff may themselves link to several other packages).

How can a package maintainer tell what libraries a package DSO/DLL is statically linked to?  This is in general unanswerable as the dependency chains depend on the OS and what options were used when the static libraries were built.  But some hints:

  * For a package already on CRAN, look at the installation logs for macOS and Windows linked as `install log' from the CRAN check logs on those platforms.

  * Run pkg-config --static --libs, preferably on macOS and/or Windows (with rtools installed).

  * Submit an under-preparation package to mac-builder and win-builder and look in the installation logs to see which libraries are included at the linking step(s).

It can be tricky to know what is a system library on macOS -- ICU (libicucore provided by macOS) expat, libbz2, libcurl, libxml-2.0, zlib and X11 libraries are usually (but not always) linked dynamically from the OS or XQuartz.  If you are using a Mac,

     otool -L /path/to/installed pkg/libs/pkgname.so

gives the definitive list of dynamic dependencies (direct or indirect).

Projects requiring licence redistribution
*****************************************

A partial list:

     gdal
     hdf4
     hdf5
     icu
     ImageMagick
     lapack
     lerc
     libarchive
     libgcrypt (used by libcurl on Windows)
     libtbb (shipped by RcppParallel)
     libtiff
     libwebp
     netcdf
     openjpeg2
     openssl (provides libcrypto and libssl)
     pcre
     pcre2
     protobuf
     szip

gdal says it is under an MIT-style licence but the full licence includes several components under a BSD-style licence.

jpeg requires copyright statements to be reproduced.