[R] problem on upgrading to RH6.2 (Update)

[Christian Posse]

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._