similar to: Missing dependencies in installing R-base-1.0.0-1

I am running linuxppc 2.1.128 on a pmac 8500/200 604e. R 0.63 builds and installs without errors. The compiler is egcs 102 pre and binutils 2.9.1.0.15. When attempting to load modreg with the library command the following error is returned. Error in dyn.load(file) : unable to load shared library "/usr/local/share/R/library/modreg/libs/modreg.so" How can I debug this problem?

Hi, there I'm totally new to this. I used to use SPLUS, but think maybe useful to try R at home. But seems it doesn't like me. I got error message says ld: cannot open -lg2c: No such file or directory My OS is openlinux 2.3. I use egcs-2.91.66. I searched under /lib/egcs-2.91.66/ but found no libg2c.a. There's only a libgcc.a. Thought maybe g77 people changed

Hi, I appear to have a slight problem compiling R0.65.0 under Linux (slackware) using g77. By simply typing configure then make, I obtain a binary which when "ldd" does not contain the f2c library. I therefore cannot load any libraries containing fortran code (I obtain unresolved symbol messages from R.X11 and an unable to load shared library from dyn.load(file)). If I change the

NAME Douglas Bates EMAIL bates@stat.wisc.edu VERSION 0.63.3 PLATFORM i386-unknown-linux SYSTEM Debian 2.1 CC/FC/MAKE egcs/g77/make NAME Martyn Plummer EMAIL plummer@iarc.fr VERSION 0.63.3 PLATFORM i386-unknown-linux SYSTEM Redhat 5.1 CC/FC/MAKE gcc/egcs-g77/make NAME Göran Broström EMAIL gb@stat.umu.se VERSION 0.63.3 PLATFORM

Only three entries thus far. Please keep them coming in. -k NAME Martyn Plummer EMAIL plummer@iarc.fr VERSION 0.63.3 PLATFORM i386-unknown-linux SYSTEM Redhat 5.1 CC/FC/MAKE gcc/egcs-g77/make NAME Douglas Bates EMAIL bates@stat.wisc.edu VERSION 0.63.3 PLATFORM i386-unknown-linux SYSTEM Debian 2.1 CC/FC/MAKE egcs/g77/make NAME Thomas

I am trying to use predict.glm to validate a logistic model. Using predictions <- predict.glm(logit.model, type="response", dataframe="validate") I get the predictions from the original dataframe, not the validation data frame. Am I missing an input to the method or is this what is supposed to happen?

I am new to Linux and its ways, and so I am having a bit of trouble compiling R. The system I am using is Caldera Open Linux 2.4. I have egcs and g77 version 2.91.66 installed and they seem to work fine. When I try to run the configure script for R, it quits at the test of g77 with an error "Can't find -lg2c". Does this error mean I am missing a library, and if so, which one?

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/ >

Working on a Red Hat (not Mandrake) Linux and trying to load my library I get (sorry, can't copy it all, working remotely) gcc -shared -o ..... /user/bin/ld: cannot find -lg2c Does anyone know what the g2c library iss, and if I can download and compile it for Red Hat (I definitely didn't mean to type f2c in the above) Thanks Jonathan

This may be considered a newbie question, and for me, yum is a new tool. I have discovered via yum, I am *supposed* to have libf2c (386) and libf2c (x86-64) installed. Searching the two libs, I find I only have the 32-bit version installed, and I need both. Should I use yum to remove the pkgs, and then reinstall, or should I use rpm to do the installs? Again, I'm from the BSD camp, so

Hi, I'm running 0.64 using the gnome interface on a linuxppc. The code configures and builds without problems. In using the non gnome interface the PS output in demo(graphics) is normal. In the gnome version there is no text. The graphics are normal. Other than this it appears stable. Is this a known problem? Details powermac 8500 604e/200MHz linux 2.2.5 redhat 4.2 egcs 1.1.2 binutils

Ok, I did the following experiment dyn.load("/usr/local/lib/libf2c.so.2.0") dyn.load("try.so") .Fortran("try", 10.5) where try.so contains the following compiled subroutine subroutine try(x) double precision x write(*,*) x return end It worked just fine (at least here on my FreeBSD machine at home). So it seems that it will be

The current development version dies in qbeta() when compiled with egcs -O, egcs 1.0.2 and glibc 2.0.7 (RedHat versions). Since this also kill the F and t distributions, it doesn't exactly do wonders for R's usefulness... Anyone else seeing this or has my setup just gone out of whack? It does look pretty much like a clear compiler bug when inlining math functions (storing temporaries

Some machines in our department use RedHat 5.2 Linux but, to maintain consistency with other machines, the compilers as from egcs-1.0.3, as shown below. When I compile R-0.63.3 on these systems I can't pass the tests in "make check". The base-Ex.R file stops execution with the error shown below. ... Running all help() examples ... ../../bin/R --vanilla < base-Ex.R >

Hi! What am I doing wrong here? Mission: Delete old empty sub mailboxes in our Public mailspace acl-file contents: MailingLists user=dag lrwstipekxa MailingLists/* user=dag lrwstipekxa Didn't work from my mail client so tried: Command tried: % doveadm mailbox delete -s MailingLists/Glibc -u dag doveadm(dag): Error: Can't delete mailbox MailingLists/Glibc: Permission

Just so folks know, all the modern variants of EGCS (now named gcc) out there appear to be producing occasionally bogus x86 FPU code at -O1 or higher. Guess what... Vorbis trips the bug whatever it is. I just grabbed and built the latest CVS code, and it's also broken. I'm constructing a small failure case example for a bug report now. It looks like FPU arithmetic into a register

>>>>> Thomas Lumley writes: > On Fri, 1 Aug 1997, Kurt Hornik wrote: >> Thomas, >> >> Could you add the "-lf2c" at the end of the line >> @$(LD) $(SHLIBLDFLAGS) -o $(LIBNAME).so $(OBJS) >> in acepack's src-c/Makefile? >> >> I ran across an identical pow_dd problem recently with another package. >> Did we always need

Hi folks, The folks on RedHat who have been complaining of poor-quality encodes prompted us to track down the trouble, and it's a compiler bug. We have the asm .s files to prove it :-) The summary: EGCS (gcc) versions through March 1999, including up to at least gcc/egcs 2.91.66 have a serious floating point optimization bug that hits Vorbis. This is a fairly old gcc version, but RedHat

Hi folks, The folks on RedHat who have been complaining of poor-quality encodes prompted us to track down the trouble, and it's a compiler bug. We have the asm .s files to prove it :-) The summary: EGCS (gcc) versions through March 1999, including up to at least gcc/egcs 2.91.66 have a serious floating point optimization bug that hits Vorbis. This is a fairly old gcc version, but RedHat

>R INSTALL dse rlibs >Installing package `dse' ... >libs >gcc -g -fpic -I/usr/local/R-0.61/include -c dsefor.c -o dsefor.o >/tmp/cca02533.i:1: numeric constant with no digits >/tmp/cca02533.i:1: numeric constant with no digits >... >is there something wrong with my gcc or is there some >option missing somewhere? >I suspect the problem might have to do with