problem on upgrading to RH6.2 (Update)
Prof. Ripley was correct suggesting a title with an RH6.2 problem and not a problem concerning the ts package. In fact, it is far worse than I thought and is similar to what Jair Oksanen and Peter Dalgaard wrote. The situation is the following: - The RPM R-base-1.0.1-2.i386.rpm from statlib works fine under RH 6.2. Loading the libraries in the base works fine too. Most contrib packages installed with this version of R with R INSTALL work except for tripack, acepack, akima, mclust (segfault!), leaps, and so on. (I stopped trying all of them.....) Strange messages of undefined symbols :
library(tripack)
Error in dyn.load(x, as.logical(local), as.logical(now)) :
unable to load shared library
"/usr/lib/R/library/tripack/libs/tripack.s
o":
/usr/lib/R/library/tripack/libs/tripack.so: undefined symbol: ?
The situation is far worse with the version of R built by myself
after having downloaded the *.tgz file from statlib. With this
version, R base works fine, but impossible to load successfully
any library, even the one in the base packages
(Just in case, the R-base*src.rpm provides the same source code
and therefore I got the same problems).
Note, my PC is pure vanilla. I just got it brand new and I installed
RH6.2. Then I tried to build R and got all these problems.
RH6.2 comes with
<18>root at cuky/R: gcc --version
egcs-2.91.66
How can I compare that with what Peter Dalgaard wrote
( I have been confused for a long time between the different
brands of gcc, true gcc or egcs flavor).
Peter Dalgaard wrote:
You're doing better than me, I just get a segfault... It seems that something is seriously wrong with dyn.loading Fortran on RH6.2. Upgrading the C/Fortran compilers to gcc 2.95.1 or newer seems to cure it. I'll be d**ned if I can figure out what is going wrong, but .so files created with 2.95.1 work with R compiled with egcs-1.1.2 and .so files created with egcs-1.1.2 cause segfaults when used with R compiled with 2.95.1, so the problem is likely in the shared libraries themselves. Thanks for all answers so far. Christian ----- Original Message ----- From: "Jari Oksanen" <jhoksane at ecology.helsinki.fi> To: "r-help" <r-help at stat.math.ethz.ch> Sent: Thursday, May 25, 2000 2:39 AM Subject: Re: [R] problem on upgrading to RH6.2 (was problem with ts pack plummer at iarc.fr said:
On 24-May-00 Prof Brian D Ripley wrote: On Wed, 24 May 2000, Christian Posse wrote:
>> >> I just encountered a problem with the ts package: >> >> >
library(ts) >> Error in dyn.load(x, as.logical(local), as.logical(now)) : >> unable to load shared library >> "/usr/ local/lib/R/library/ts/libs/ts.so": >> /usr/local/lib/R/library/ts/ libs/ts.so: undefined symbol: ma > ... > I have no idea what is going on: ma is not a symbol in the ts package, so the problem is definitely elsewhere. We do know that this works correctly when compiled and run on an RH6.2 system.
I'm afraid dlerror() can return garbage on RH6.2 so the "undefined symbol: ma" message is probably not helpful.
The latest R RPM for Red Hat Linux is compiled on RH6.2 and works fine. I suggest you try that.
I have similar problems with R 1.0.1 on RH6.2 (pre-compiled rpm binaries). Some of the old packages ceased to work and when I tried to re-install them through `R INSTALL package.tar.gz', some just fail and give similar error messages. My `ts' works, but it is of the old original version, and I don't dare to check if it stops working after re-installation. However, re-installed `tripack' gives the following error message: > library(tripack) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/usr/lib/R/library/tripack/libs/tripack.so": /usr/lib/R/library/tripack/libs/tripack.so: undefined symbol: ? If I first gunzip the package, I get another undefined symbol, but the net effect is the unchanged: a failure to load a library. Otherwise the message is the same as for `ts' above. Downgrading to the old binaries of the package does not help, since they fail for other reasons, in this case because they can't find e_wsfe. This, I think, is caused by libf2g growing independent of libf2c which had this function (originally in libI77.a). cheers, jari oksanen -- Jari Oksanen - Dept Ecol Env Sci, Univ Helsinki, 15140 Lahti Ph. +358 3 89220312, Fax -- 89220289, Mobile +358 40 5136529 jari.oksanen at helsinki.fi http://www.helsinki.fi/~jhoksane -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. -.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. _._ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._