From therneau at mayo.edu  Wed Apr 13 22:47:07 2011
From: therneau at mayo.edu (Terry Therneau)
Date: Wed, 13 Apr 2011 15:47:07 -0500
Subject: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem
In-Reply-To: <19878.2128.292065.275960@max.nulle.part>
References: <1302717605.12894.28.camel@nemo>
	<19877.60604.384710.321827@max.nulle.part>
	<1302724885.12894.61.camel@nemo>
	<19878.2128.292065.275960@max.nulle.part>
Message-ID: <1302727627.12894.79.camel@nemo>


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 is easy to test elsewhere. 
  I don't anticipate that every user will erase all libraries and
reinstall with each new R release.  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.
> | 
> | 
>



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