similar to: g2c library

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

To: jnf@pcisys.net Subject: Compilation of R under Caldera OpenLinux 2.2 > On Sat, 28 Aug 1999 jnf@pcisys.net wrote: > > > > I am attempting to compile R-0.64.2 under Caldera OpenLinux 2.2. I have > > KDE installed but not gnome. When I ran configure, it correctly > > indicated that gnome is not installed. However when I then ran make, I > > received errors

Hello, Here is a problem I have had trying to install locfit, the package for R. I have already contacted Clive Loader who thinks the problem has more to do with R than locfit, so here is the point : The version of R I am currently running is R-base-0.90 that I installed using the R-base-0.90.1-1.i386.rpm package. I dowloaded the locfit package available at the CRAN site and ran : R INSTALL

As of quite recently I experience failures to compile source packages. Messages like * Installing *source* package 'dse1' ... ** libs g77 -mieee-fp -fPIC -g -O2 -c dsefor.f -o dsefor.o gcc -shared -o dse1.so dsefor.o -L/usr/lib/gcc-lib/i486-linux/3.3.3 -L/usr/lib/gcc-lib/i486-linux/3.3.3/../../.. -lfrtbegin -lg2c-pic -lm -lgcc_s -L/usr/lib/R/bin -lR /usr/bin/ld: no se puede

Full_Name: Russell Price Version: 0.64.2 OS: Redhat 6.0 Submission from: (NULL) (128.171.242.1) When attempting to compile, I get the following error message: gcc -g -O2 -I../include -I../../src/include -c d1mach.c -o d1mach.o gcc: Internal compiler error: program cc1 got fatal signal 6 make[2]: *** [d1mach.o] Error 1 make[2]: Leaving directory `/usr/local/src/R-0.64.2/src/nmath' make[1]:

To: jnf@pcisys.net Subject: Compilation of R under Caldera OpenLinux 2.2 > On Sat, 28 Aug 1999 jnf@pcisys.net wrote: > > > > I am attempting to compile R-0.64.2 under Caldera OpenLinux 2.2. I have > > KDE installed but not gnome. When I ran configure, it correctly > > indicated that gnome is not installed. However when I then ran make, I > > received errors

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?

Hi, I am sick of remembering things, when configuring and compiling, so I would like to help make the cvs configuring and building of llvm easier. Here are a set of empty files that produce broken f771,jc1 and cc1obj. At least the make does not break. Right now I am only compiling and linking in these two new files via shell scripts as a test. If you are interested, I can integrate this into the

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

I hope someone can point me, a newcomer to building R as well as 64-bit R, in a useful direction. I have a dual Opteron 275 box running RedHat EL4. I ran configure successfully, and, then, get the following error while running make: make[4]: Entering directory `/tmp/R-2.2.0/src/modules/lapack' g77 -fPIC -g -O2 -ffloat-store -c dlamc.f -o dlamc.lo g77 -fPIC -g -O2 -c dlapack0.f -o

hello, I create a package which includes C code and Lapack. But when I run " R CMD check ". an error message, "/usr/bin/ld: cannot find -lfrtbegin " occurs. could you tell me what is the problem? the detailed message is as follows: [credsim@confsys ~/src]$ R CMD check var * checking for working latex ... OK * using log directory '/home/credsim/src/var.Rcheck' *

.. R is now configured for sparc-sun-solaris2.6 Source directory: . Installation directory: /unsup/R-0.64.2 C compiler: gcc -g -O2 FORTRAN compiler: g77 -O2 Gnome support: no $ gcc --version egcs-2.91.66 $ g77 --version GNU Fortran 0.5.24-19981002 "make check" later fails. The failure is in the test of the eigen() function. The

Error running 'make buildworld' on FBSD 4.9 RC1(i386) source (see below); error replicated twice.....could this simply be due to a corruption of the downloaded ISO file? The softlink created before the initial error message appears to have been created OK, so not sure where the error is being generated. ***************************************************************** ===>

I downloaded the latest wine from the cvs site and ran its ./tools/wineinstall. It ran for quite a while and croaked on /wine/server/semaphore.c. Basically, gcc says "Internal compiler error: program cc1 bog fatal signal 11". The compiler is 2.91.66 (aka egcs-1.1.2 release) and compiles other programs including 2.4.1 & 2.4.2 Linux kernels just fine. I am puzzled what 'fatal

Howdy, I'm experiencing a segmentation fault when trying to load mclust.so from mclust-1.1-4. I'm using R-1.3.1 on RedHat 6.2, and `gcc --version` reports "egcs-2.91.66". Any ideas? -Andy Package install: > install.packages("mclust") [stuff omitted] Installing source package `mclust'

I saw that if I add a c to my Dial string as follows: exten => s,3,Dial(Zap/g2c/18005551212) That it will not consider that call as answered until the called party presses #. When the number dialed picks up does a bridge of the call immediately instead of waiting for the # key. I am using a PRI, does that make a difference???? -------------- next part -------------- An

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

Per a discussion I started earlier, I've encoded a wav with oggenc's from various different compilers. And so... MSVC (as distributed on vorbis.com): 3,502,399 bytes BCC (WinME, BCB4 Std SP 1): 3,502,555 bytes EGCS (Linux 2.4.1, egcs 2.91.66): 3,516,935 bytes GCC (Linux 2.4.1, gcc 2.95.2): 3,516,935 bytes BCC, EGCS, and GCC I compiled myself from last night's CVS snapshot. The

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