Problem with dyn.load in R 2.13.0

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with dyn.load in R 2.13.0

Therneau, Terry M., Ph.D.
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0

Dirk Eddelbuettel

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 | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0

Martin Morgan
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0

Simon Urbanek
In reply to this post by Therneau, Terry M., Ph.D.
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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0 -- the real problem

Therneau, Terry M., Ph.D.
In reply to this post by Dirk Eddelbuettel

On Wed, 2011-04-13 at 15:32 -0500, Dirk Eddelbuettel wrote:

> Terry,
>
> You replied to
>  
>   From: Terry Therneau <[hidden email]>
>   To: Dirk Eddelbuettel <[hidden email]>
>   Cc: [hidden email]
>   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.
> |
> |
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0 -- the real problem

Simon Urbanek

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 <[hidden email]>
>>  To: Dirk Eddelbuettel <[hidden email]>
>>  Cc: [hidden email]
>>  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.
>> |
>> |
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0

Therneau, Terry M., Ph.D.
In reply to this post by Simon Urbanek

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-8        LC_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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with dyn.load in R 2.13.0 -- the real problem

Kasper Daniel Hansen-2
In reply to this post by Simon Urbanek
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
<[hidden email]> 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 <[hidden email]>
>>>  To: Dirk Eddelbuettel <[hidden email]>
>>>  Cc: [hidden email]
>>>  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.
>>> |
>>> |
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel