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
> On Jul 26, 2019, at 8:34 AM, Dmitriy Selivanov <selivanov.dmit...@gmail.com>
> wrote:
>
> Thank you Simon - I will try with the static library.
>
> >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.
>
> 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.urba...@r-project.org>
> wrote:
> 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
>
>
> > On Jul 25, 2019, at 8:18 AM, Dmitriy Selivanov
> > <selivanov.dmit...@gmail.com> wrote:
> >
> > 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.
> >
> > --
> > Regards
> > Dmitriy Selivanov
> >
> > [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>
>
> --
> Regards
> Dmitriy Selivanov
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
