Skip to content

Linking to other package shared library

4 messages · Dmitriy Selivanov, Simon Urbanek

Original
Dmitriy Selivanov
# 
Dear r-sig-mac mailing list,
I have difficulties to solve one problem - I don't understand on how my
package can link to another package which is built by CRAN. More on this
below.

I'm a developer of rparse package (
https://cran.r-project.org/web/packages/rsparse/). This package links to
float pkg (https://cran.r-project.org/web/packages/float/index.html). This
is done in configure script and with installation from source it works just
fine. But there is an issue when installing rsparse from CRAN binaries. In
this case rsparse shared library references the path of the float shared
library which is recorded during the build on CRAN machine. And it is
different from the path on user machine (On cran it is
@rpath/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.6/float/libs/float.so).
In
fact the warning is produced by CRAN checks -
https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/float-00install.html
)
I've tried to fix this be using `.onLoad` hook where I run
`install_name_tool -change ...`, but it seems `dyn.load` is called before
.onLoad hook...

What will be the correct way to solve this issue?

Thanks in advance.
Simon Urbanek
# 
See R-exts 5.8: you cannot link directly to other package or its libraries. It is not possible is a portable way across platforms for many reasons including those that you are hitting here. If a package exposes some C-level functionality to other packages, you can use it and R provides a way to obtain access to the function - see R-exts 5.4.3.

There are ways to make a *static* library available, because that allows your package to be installed without actually requiring the presence of the other package at install time. But, again, the package has to make it explicitly available since you cannot guarantee that your package won't break as it's technically internal to the other package. That said, it seems the there is a bug in float since it provides the wrong flags to link against its library (float:::ldflags()). It should really just use system.file("libs","libfloat.a",package="float") - you may want to contact the maintainer of float about that. Flags cannot be hard-coded at install time because the package can be installed in any location, moreover staged install is preformed in a direction separate from the R library anyway.

Cheers,
Simon
Dmitriy Selivanov
# 
Thank you Simon - I will try with the static library.
use it and R provides a way to obtain access to the function - see R-exts
5.4.3.

My case is a little bit trickier (at least as it looks for me) - float pkg
exposes single precision BLAS and LAPACK. rsparse use it in the C++ code
implicitly via Armadillo library. This is due to the unfortunate fact that
R doesn't ship single precision blas and lapack.


On Thu, Jul 25, 2019 at 11:53 PM Simon Urbanek <simon.urbanek at r-project.org>
wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Thanks, I looked at the actual implementation in float (float:::ldflags_string) and it seems that it actually gets the static case right, so it should work. I would suggest that the author (I took the liberty to CC) make static=TRUE the default since the dynamic linking simply doesn't work in general.

Cheers,
Simon