[Rd] Problem with dyn.load in R 2.13.0 -- the real problem

[Kasper Daniel Hansen]

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.urbanek at 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 <therneau at mayo.edu>
>>>  To: Dirk Eddelbuettel <edd at debian.org>
>>>  Cc: cran at 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>