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

[Simon Urbanek]

Pariksheet,

dynamic linking won't work, compile a static version with PIC enabled. If the subproject is autoconf-compatible this means using --disable-shared --with-pic. Then you only need to add libfoo.a to your PKG_LIBS.

Cheers,
Simon




> On Oct 19, 2021, at 4:13 PM, Pariksheet Nanda <pariksheet.nanda using uconn.edu> wrote:
> 
> 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
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>