shared object location
as a motivating example, consider the case where multiple/many R
packages are being developed that all use the same shared object
functions.
each time (during development) that the shared object file changes we
could go alter every single R package directory, or simply have the R
package utilize the most recent single copy of the shared object's
functions.
this is essentially what happens already with most programs and the
common libraries in /usr/lib, /usr/local/lib, etc.
but during development of the library, it's preferable to keep this
library out of those system-level trees, and instead somewhere more
local (e.g. in the developer's home directory, or a location set aside
by a team of developers, e.g. /dev/lib).
then i would like for each of the R packages to do something like
'library.dynam("testlib1")', looking along the LD_LIBRARY_PATH for the
R session (which will include /dev/lib), for the library /dev/lib/
testlib1.so.
but it appears library.dynam can ONLY search inside package
contents... is this correct?
i can keep telling every package writer to include 'dyn.load("/dev/lib/
testlib1.so")' somewhere in their package, but this is fragile (as
dyn.load requires an exact path to be specified, instead of using
LD_LIBRARY_PATH).
so it appears i either have fragility, or an error-prone process of
updating the .so files in each R package separately each time the
library changes (which is frequently).
i have to imagine there is some method in R that i just cannot
identify that will allow for linking/loading of shared objects along
the LD_LIBRARY_PATH.
On Jan 30, 5:52?pm, Murat Tasan <mmu... at gmail.com> wrote:
The primary reason is for development. I do install via the traditional R CMD INSTALL (or variant) method, but I want to keep the C code external from the R package. In particular, I want to be able to modify the C code (and thus the compiled .so library functions) without having to constantly re- install the R package, or constantly copy the shared object library to the /libs/ subdirectory in the R package directory. The crux of the matter is that this seems do-able: it basically works using dyn.load, just not easily with library.dynam, which is what confuses me. The vast majority of other UNIX-ish applications will somewhere allow me to specify a non-standard library location, if needed In many cases, this is done (in an ad-hoc, and thus unstable manner) using LD_LIBRARY_PATH, but this doesn't seem to be working for me in this instance. On Jan 29, 4:53?pm, Seth Falcon <s... at userprimary.net> wrote:
Hi,
On 1/29/10 12:58 PM,MuratTasan wrote:
problem is, i haven't been able to do this yet.
my workaround is to constantly swap into myRPackage/libs/ directory a version of the shared object library called myRPackage.so, and load it via the useDynLib(...) directive in the NAMESPACE file of the package. ?but this is cumbersome and doesn't allow other people to have a single version of the R package to use as part of a team effort to debug/test both the package's R code and my C code for the library functions.
hopefully this makes a bit more sense, and if anyone has any tips on how R actually loads shared objects it would be greatly appreciated.
I'm afraid I don't have a solution for you. ?Reading through your post, I'm confused about why you want to have your .so file outside of the package?
Why not follow the usual scheme and R CMD INSTALL yourPkg with the version of R code and C code you want to use/test. ?This would best allow other people to have a single version of the R package, no?
+ seth
-- Seth Falcon | @sfalcon |http://userprimary.net/user
______________________________________________ R-h... at r-project.org mailing listhttps://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guidehttp://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
______________________________________________ R-h... at r-project.org mailing listhttps://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guidehttp://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.