Re: [Rd] Problem with dyn.load in R 2.13.0
On 13 April 2011 at 13:00, Terry Therneau wrote:
| I have a test directory for the survival suite, and dyn.load has ceased
| to work in it. Below shows the log:
|
| tmt1075% R --vanilla
|
| R version 2.12.2 (2011-02-25)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
| dyn.load('survival.so')
| q()
[...]
|
| tmt1076% R13 --vanilla
|
| R version 2.13.0 RC (2011-04-11 r55409)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
| dyn.load('survival.so')
| Error in dyn.load(survival.so) :
| unable to load shared object
| '/people/biostat2/therneau/research/surv/Rtest/survival.so':
| libR.so: cannot open shared object file: No such file or directory
| q()
|
| --
|
| Is the issue that the .so file must have been created with the R2.13
| script? That's not what the error message says, however. It almost
| looks like it is ignoring my first argument and looking instead for
| libR.
What does 'ldd /path/to/your/survial.so' say? Does the system find libR.so?
I have no issues whatsoever on my Ubuntu box with the packages distributed
via CRAN (and now also a PPA if you want alpha/beta/rc builds) based on the
underlying Debian package I maintain.
I have a (pretty visible) hourly cronjob that drives our littler /usr/bin/r
frontend to do the CRANberries summaries---and even while /usr/bin/r was last
built under R 2.11.1, it continued to work merrily under R 2.12.0, 2.12.1,
2.12.2, and 2.13.0 prereleases:
edd@max:~$ r --version | head -4
r ('littler') version 0.1.3
svn revision 178 as of 2010-01-05 20:57:41
built at 20:08:17 on Oct 11 2010
using GNU R Version 2.11.1 (2010-05-31)
edd@max:~$
edd@max:~$ R --version | head -1
R version 2.13.0 RC (2011-04-07 r55373)
edd@max:~$
Both use the same shared library version libR.so from whichever current
r-base-core is installed.
So I see no particular breakage. Recompiling your project may also be a start.
Hth, Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0
On 04/13/2011 11:34 AM, Dirk Eddelbuettel wrote:
On 13 April 2011 at 13:00, Terry Therneau wrote:
| I have a test directory for the survival suite, and dyn.load has ceased
| to work in it. Below shows the log:
|
| tmt1075% R --vanilla
|
| R version 2.12.2 (2011-02-25)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
| dyn.load('survival.so')
| q()
[...]
|
| tmt1076% R13 --vanilla
|
| R version 2.13.0 RC (2011-04-11 r55409)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
| dyn.load('survival.so')
| Error in dyn.load(survival.so) :
| unable to load shared object
| '/people/biostat2/therneau/research/surv/Rtest/survival.so':
| libR.so: cannot open shared object file: No such file or directory
| q()
|
| --
|
| Is the issue that the .so file must have been created with the R2.13
| script? That's not what the error message says, however. It almost
| looks like it is ignoring my first argument and looking instead for
| libR.
What does 'ldd /path/to/your/survial.so' say? Does the system find libR.so?
Maybe R CMD ldd /path/to/your/survival.so to pick up whatever
environment R configures.
Martin
I have no issues whatsoever on my Ubuntu box with the packages distributed
via CRAN (and now also a PPA if you want alpha/beta/rc builds) based on the
underlying Debian package I maintain.
I have a (pretty visible) hourly cronjob that drives our littler /usr/bin/r
frontend to do the CRANberries summaries---and even while /usr/bin/r was last
built under R 2.11.1, it continued to work merrily under R 2.12.0, 2.12.1,
2.12.2, and 2.13.0 prereleases:
edd@max:~$ r --version | head -4
r ('littler') version 0.1.3
svn revision 178 as of 2010-01-05 20:57:41
built at 20:08:17 on Oct 11 2010
using GNU R Version 2.11.1 (2010-05-31)
edd@max:~$
edd@max:~$ R --version | head -1
R version 2.13.0 RC (2011-04-07 r55373)
edd@max:~$
Both use the same shared library version libR.so from whichever current
r-base-core is installed.
So I see no particular breakage. Recompiling your project may also be a start.
Hth, Dirk
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0
We have no details, but my wild guess would be that you did not re-build the
package for 2.13.0 and you have static libR in 2.13.0 yet dynamic in 2.12.2.
Cheers,
Simon
On Apr 13, 2011, at 2:00 PM, Terry Therneau wrote:
I have a test directory for the survival suite, and dyn.load has ceased
to work in it. Below shows the log:
tmt1075% R --vanilla
R version 2.12.2 (2011-02-25)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
dyn.load('survival.so')
q()
tmt1076% R13 --vanilla
R version 2.13.0 RC (2011-04-11 r55409)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
dyn.load('survival.so')
Error in dyn.load(survival.so) :
unable to load shared object
'/people/biostat2/therneau/research/surv/Rtest/survival.so':
libR.so: cannot open shared object file: No such file or directory
q()
--
Is the issue that the .so file must have been created with the R2.13
script? That's not what the error message says, however. It almost
looks like it is ignoring my first argument and looking instead for
libR.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem
On Apr 13, 2011, at 4:47 PM, Terry Therneau wrote: On Wed, 2011-04-13 at 15:32 -0500, Dirk Eddelbuettel wrote: Terry, You replied to From: Terry Therneau thern...@mayo.edu To: Dirk Eddelbuettel e...@debian.org Cc: c...@r-project.org Subject: Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem but dropped r-devel. On purpose? No, not on purpose. Corrected. This still looks like a local config issue about local libraries to me. Dirk I fail to see how. Running the newest release of R 2.13, if I issue a library() command for something installed earlier in R_LIBS_USER, something I expect lots of people to do, and that library has a .so file with reference to the now-nonexistent Rlib.so file, an error ensues. This depends on the OS - on Linux the path to libR is not embedded in the package's .so, so R will happily try to load whatever libR is current - regardless whether that breaks or not. Again, this is entirely OS-dependent. Also in your case you have an entirely different build of R so your issue is independent of R version - you'd get exactly the same issue if both R builds were 2.12.2. This is easy to test elsewhere. I don't anticipate that every user will erase all libraries and reinstall with each new R release. Well, then they are entirely on their own. Major releases are not guaranteed to be binary compatible and often they are not. Depending on the subset of the features a package may use it may or may not work, but it is never guaranteed. The first thing any user should do after R upgrade is to run update.packages. But, again, this is not really related to your problem ;). I suppose your admin has forgotten to use --enable-R-shlib when building 2.13.0. Cheers, Simon At work particularly, the default R release changes without user intervention; the system admin is not going to go looking for all local downloads. (A lot of people use R_LIBS_USER, as they don't have permission to put things elsewhere -- this includes me.) The error message for logspline is great as it tells them what to do. I'm only looking for a better one in the case I found. On 13 April 2011 at 15:01, Terry Therneau wrote: | Dirk's comment made it clearer: | | On Wed, 2011-04-13 at 13:34 -0500, Dirk Eddelbuettel wrote: | What does 'ldd /path/to/your/survial.so' say? Does the system find | libR.so? | | | tmt1077% pwd | /people/biostat2/therneau/research/surv/Rtest | tmt1078% ldd survival.so | libR.so = not found | libc.so.6 = /lib64/libc.so.6 (0x2aede2d94000) | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) | | However, this is a survival.so file created by R12, and that version has | a libR.so in RHOME/lib. Version R2.13 has no such file. If I remake | the .so file using R 2.13: then I get | | tmt1084% ldd survival.so | libc.so.6 = /lib64/libc.so.6 (0x2b656a2f1000) | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) | | And R | | -- | | So, the real problem is a misleading error message. I have several | pacakges loaded into my own ~/Rlib. When I access one of these from | version 2.13 I get variable errors, or success. | | tmt1087% R13 --vanilla | | R version 2.13.0 RC (2011-04-11 r55409) | Copyright (C) 2011 The R Foundation for Statistical Computing | ISBN 3-900051-07-0 | Platform: x86_64-unknown-linux-gnu (64-bit) | ... | | library(logspline) | Error: package 'logspline' was built before R 2.10.0: please re-install | it | | library(quadprog) | Error in dyn.load(file, DLLpath = DLLpath, ...) : | unable to load shared object | '/people/biostat2/therneau/Rlib/quadprog/libs/quadprog.so': | libR.so: cannot open shared object file: No such file or directory | Error: package/namespace load failed for 'quadprog' | | library(xtable) | | | My problem is solved, but is this a user confuser issue that should be | addressed in the release? | | Terry T. | | __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0
On Wed, 2011-04-13 at 16:45 -0400, Simon Urbanek wrote: We have no details, but my wild guess would be that you did not re-build the package for 2.13.0 and you have static libR in 2.13.0 yet dynamic in 2.12.2. Cheers, Simon Per my prior note, my guess at the root of the issue is use of user libraries, which is common here. Here are futher details if that helps. R2.13 was downloaded and built this AM in my ~/temp directory, using the standard ./configure make Then a copy of the shell script was copied to in ~therneau/bin/R13 for my convenience. I paid very little attention to the output of configure. This is running on a shared server using CentOS release 5.5 (98 users at the moment). R2.12.2 is centrally available. sessionInfo() R version 2.13.0 RC (2011-04-11 r55409) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=C [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base I can't find a libR.so anywhere -- perhaps it's static. tmt1119% pwd /people/biostat2/therneau/temp/R-rc tmt1120% find . -name 'libR*' ./src/extra/blas/libRblas.so ./src/main/libR.a ./src/modules/lapack/libRlapack.so ./src/nmath/standalone/libRmath.pc.in ./src/unix/libR.pc.in ./lib/libRblas.so ./lib/libRlapack.so Thanks for everyone's help. Terry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem
Terry You may not be aware of this, but the new default in R is to use a user library which is architecture and R-version dependent. Ie. if you do not play around with R_USER_LIBS or .Rprofile, functions like R CMD INSTALL or install.packages will default to something like (from my current version) /home/bst/student/khansen/R/x86_64-unknown-linux-gnu-library/2.12 My home is /home/bst/student/khansen so it puts it inside R / ARCHITECTURE / VERSION Ok, it requires that you accept an R directory in your top level home, but this is in almost all cases much preferred to playing with R_USER_LIBS yourself (in my humble opinion). Of course, this requires a re-install of all packages when you switch R version and it also requires that you install each package separately under each R you are using. But it highly minimize the possibility of errors. I don't think installed packages are assured to be compatible across R versions in any way. Kasper On Wed, Apr 13, 2011 at 5:05 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Apr 13, 2011, at 4:47 PM, Terry Therneau wrote: On Wed, 2011-04-13 at 15:32 -0500, Dirk Eddelbuettel wrote: Terry, You replied to From: Terry Therneau thern...@mayo.edu To: Dirk Eddelbuettel e...@debian.org Cc: c...@r-project.org Subject: Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem but dropped r-devel. On purpose? No, not on purpose. Corrected. This still looks like a local config issue about local libraries to me. Dirk I fail to see how. Running the newest release of R 2.13, if I issue a library() command for something installed earlier in R_LIBS_USER, something I expect lots of people to do, and that library has a .so file with reference to the now-nonexistent Rlib.so file, an error ensues. This depends on the OS - on Linux the path to libR is not embedded in the package's .so, so R will happily try to load whatever libR is current - regardless whether that breaks or not. Again, this is entirely OS-dependent. Also in your case you have an entirely different build of R so your issue is independent of R version - you'd get exactly the same issue if both R builds were 2.12.2. This is easy to test elsewhere. I don't anticipate that every user will erase all libraries and reinstall with each new R release. Well, then they are entirely on their own. Major releases are not guaranteed to be binary compatible and often they are not. Depending on the subset of the features a package may use it may or may not work, but it is never guaranteed. The first thing any user should do after R upgrade is to run update.packages. But, again, this is not really related to your problem ;). I suppose your admin has forgotten to use --enable-R-shlib when building 2.13.0. Cheers, Simon At work particularly, the default R release changes without user intervention; the system admin is not going to go looking for all local downloads. (A lot of people use R_LIBS_USER, as they don't have permission to put things elsewhere -- this includes me.) The error message for logspline is great as it tells them what to do. I'm only looking for a better one in the case I found. On 13 April 2011 at 15:01, Terry Therneau wrote: | Dirk's comment made it clearer: | | On Wed, 2011-04-13 at 13:34 -0500, Dirk Eddelbuettel wrote: | What does 'ldd /path/to/your/survial.so' say? Does the system find | libR.so? | | | tmt1077% pwd | /people/biostat2/therneau/research/surv/Rtest | tmt1078% ldd survival.so | libR.so = not found | libc.so.6 = /lib64/libc.so.6 (0x2aede2d94000) | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) | | However, this is a survival.so file created by R12, and that version has | a libR.so in RHOME/lib. Version R2.13 has no such file. If I remake | the .so file using R 2.13: then I get | | tmt1084% ldd survival.so | libc.so.6 = /lib64/libc.so.6 (0x2b656a2f1000) | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) | | And R | | -- | | So, the real problem is a misleading error message. I have several | pacakges loaded into my own ~/Rlib. When I access one of these from | version 2.13 I get variable errors, or success. | | tmt1087% R13 --vanilla | | R version 2.13.0 RC (2011-04-11 r55409) | Copyright (C) 2011 The R Foundation for Statistical Computing | ISBN 3-900051-07-0 | Platform: x86_64-unknown-linux-gnu (64-bit) | ... | | library(logspline) | Error: package 'logspline' was built before R 2.10.0: please re-install | it | | library(quadprog) | Error in dyn.load(file, DLLpath = DLLpath, ...) : | unable to load shared object | '/people/biostat2/therneau/Rlib/quadprog/libs/quadprog.so': | libR.so: cannot open shared object file: No such file or directory | Error: package/namespace load failed for 'quadprog' | | library(xtable) | | | My problem is solved, but is this a user confuser issue
