[R-pkg-devel] How does one install a libtool generated libfoo.so.1 file into ./libs/?

Pariksheet Nanda p@r|k@heet@n@nd@ @end|ng |rom uconn@edu
Tue Oct 19 05:13:11 CEST 2021


Hi folks,

My package [1] depends on a C library libghmm-dev that's available in 
many GNU/Linux package managers.  However, it's not available on all 
platforms and if this dependency is not installed, my autoconf generated 
configure script defaults to falling back to compiling and installing 
the dependency from my bundled copy of upstream's pristine source 
tarball [2].  Now, because upstream uses automake which in turn uses 
libtool, I also use automake and libtool in my build process to hook 
into their build artifacts using SUBDIRS and *-local automake rules [3].

As you may know libtool appends `-version-info` to its generated shared 
libraries in the form "libfoo.so.1.2.3".  I'm linking against the 
bundled library which only sets the first value, namely libghmm.so.1.

The trouble is, R's installation process will only copy compiled files 
from ./libs/ that have exactly the extension ".so" and files ending with 
".so.1" are ignored.

My current workaround is to set -Wl,-rpath to the location of the 
generated ".so.1" file.  This allows the installation process to 
complete and sneakily pass the 2 canonical tests:


** testing if installed package can be loaded from temporary location
---snip---
** testing if installed package can be loaded from final location


However, not surprisingly, when I try to load the library from the final 
location after the temporary directory has been deleted it fails with:


library(tsshmm)
...
Error: package or namespace load failed for 'tsshmm' indyn.load(file, 
DLLpath = DLLpath, ...):
  unable to load shared object 
'/home/omsai/R/x86_64-pc-linux-gnu-library/4.1/tsshmm/libs/tsshmm.so':
   libghmm.so.1: cannot open shared object file: No such file or directory


I can rename the dependency from ".so.1" to ".so" to also get the 
dependent library to the final location.  But it still fails with the 
above error because the library links against the ".so.1" file and I 
would need an accompanying symlink.  I tried creating a symlink but 
can't think of how to get the symlink to the final location.  If my 
Makefile writes the symlink into ./inst/libs/libghmm.so.1 during compile 
time it is not actually installed; perhaps because the ./inst/ 
sub-directories are only copied earlier on when staging and are ignored 
later?  If I were to create that dangling symlink inside ./inst/libs/ 
instead of generating it later during compile time, devtools::install() 
complains about the broken symlink with:


cp: cannot stat 'tsshmm/inst/libs/libghmm.so.1': No such file or directory


So is there some mechanism to copy arbitrary files or symlinks to the 
final install location?  I prefer not to patch upstreams Makefile.am to 
remove their -version-info, but currently that's the only option I can 
think of.  I can't find helpful discussion surrounding this in the 
mailing list archives.

Last week when I've posted for help with my package on another issue on 
the Bioconductor mailing list, one adventurous soul tried installing the 
package using `remotes::install_gitlab("coregenomics/tsshmm")`.  This 
won't work because I haven't committed the generated autotools files; if 
anyone wants to play with it, you'll have to follow the 2 additional 
steps run by the continuous integration script, namely, unpacking 
./src/ghmm-0.9-rc3.tar.gz into ./src/ and running `autoreconf -ivf` in 
the package's top-level directory where configure.ac is located.

Any help appreciated,

Pariksheet


[1] https://gitlab.com/coregenomics/tsshmm

[2] The only patches I apply to the dependency are to fix 2 bugs for 
compiling, and to remedy a warning severe enough to be flagged by `R CMD 
check`.

[3] You can see my Makefile.am here:
https://gitlab.com/coregenomics/tsshmm/-/blob/master/src/Makefile.am



More information about the R-package-devel mailing list