[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