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 (0x00002aede2d94000) >>> | /lib64/ld-linux-x86-64.so.2 (0x00000033cd800000) >>> | >>> | 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 (0x00002b656a2f1000) >>> | /lib64/ld-linux-x86-64.so.2 (0x00000033cd800000) >>> | >>> | 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 > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel