similar to: Compiling R-1.7.0 on Mac OS X

I am trying to make R-1.5.0 from source on a new G4 system with the apple developer tools and X11 installed and with ATLAS. Running ./configure appears to end normally, but running make yields: gcc -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o Rdynload.c: In function `R_FindSymbol': Rdynload.c:942:

Hello, I am trying to build R-1.3.1 on hpux10.20 with gcc and HP's fort77. here is my configure: ./configure --prefix=/home/absd00t/local --with-readline --with-gnome=no --with-f77=fort77 I also set CXXFLAGS= -I/usr/include/Motif1.2 -I/usr/include/X11R6 -I/home/absd00t/local/include and LIBS= -L/home/absd00t/local/lib so that readline.h and libs would be found. I have parts of gnome libs so

Full_Name: Alex Buerkle Version: 1.7.0 OS: OS X Submission from: (NULL) (137.28.112.199) The configure of R-1.7.0 completed, but the build fails with error below. This failure appears to be because dlfcn.h was missing (installing it fixed the problem). The possible bug: my limited ability to read ./configure suggests that it tests for dlfcn.h, but does not fail if it doesn't find it on

Dear R users, I tried to compile R under hpux 10.20 and have sveral problems. R-1.3.1 stopped making strdup.d from strdup.c > >> gcc -I. -I../../src/include -I../../src/include > >> -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c CConverters.c -o > >> CConverters.o > >> gcc -I. -I../../src/include -I../../src/include > >>

Hi all, I'm building R for a context where I can't load dynamic libraries. I've configured the build appropriately but from what I can tell it's not currently supported: there are compile errors here and there and the mechanism for looking up base symbols (CFunTab in Rdynload.c??) seems to have been ripped out. I'm going to add enough code so that R_FindSymbol will at least

Hi, I installed R 1.3.1 on HP-UX. This caused me quite some problems. These problems did not occur with the previous version I installed, which was R version 1.2.3. First, the result of configure: R is now configured for hppa-hp-hpux10.20 Source directory: . Installation directory: /opt_local/opt/R C compiler: cc -D_HPUX_SOURCE +DA1.1 +DS1.1

I have a package that solves systems of ordinary differential equations coded as an R function (odesolve, on CRAN). The function is passed to R code, and c and Fortran code called by it uses lang4() and eval() to evaluate the R function inside a compiled c function to use in a compiled ODE solver. This works quite well, but can be slow. I'd like to be able to supply the name of a compiled

Hello, first off, thanks for all of the previous help; hopefully someone will have some insight on this question. I am attempting to track down a segmentation fault which occurs only after a detach(2) is called in the code (I have replaced the detach(2) with detach(package:DSA) and that fails as well (furthermore, I have removed the detach calls and it does not segfault)). It has proved

Our lab just picked up a G4 Powerbook (1 GHz, 1GB RAM, OS X 10.2.6). None of us have any experience with Macs but for various reasons we need to have one around for development. In any case, we've installed fink, all the Apple Developer Tools and the Dec2002updater to gcc 3.3. We're now trying to compile R 1.7.1 without too much success. First we had to get g77, which turned out to

Full_Name: Luca Barbato Version: 2.3.1 OS: Gentoo Linux/PPC Submission from: (NULL) (151.44.163.144) system informations Portage 2.1 (default-linux/ppc/ppc32/2006.0/G4, gcc-4.1.1, glibc-2.4-r3, 2.6.17-rc5 ppc) ================================================================= System uname: 2.6.17-rc5 ppc 7447A, altivec supported Gentoo Base System version 1.12.1 distcc 2.18.3

Hi. (MacOSX 10.4.6) I downloaded R-latest.tar.gz just now from src/base- prerelease on CRAN. "make" gave the following error after an apparently successful ./configure: [snip] util.c: In function 'Rf_type2char': util.c:247: warning: return discards qualifiers from pointer target type gcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/ pcre

This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to 500. On line 131 of Rdynload.c, changing #define MAX_NUM_DLLS 100 to #define MAX_NUM_DLLS 500 In development of the mlr package, there have been several episodes in the past where we have had to break up unit tests because of the "maximum number of DLLs reached" error. This error has been an inconvenience that

Dear all, I have encountered errors in compiling R-2.5.0 and R-2.4.0 in a linux machine (power-pc). I can successfully build it from the source code if I do not use the '--enable-R-shlib' option while executing the './configure' command as mentioned in rpy documentation. Using the `--enable-R-shlib' option the configure step is executed properly but the `make' crashes

Thanks Henrik this is very helpful! I will try this out on our tests and see if gcDLLs() has a positive effect. mlr currently has tests broken down by learner type such as classification, regression, forecasting, clustering, etc.. There are 83 classifiers alone so even when loading and unloading across learner types we can still hit the MAX_NUM_DLLS error, meaning we'll have to break them

I haven't been able to build yesterday's R-devel (or, as a test, R-devel_2005-03-11) on Windows XP. The error message I'm getting is to do with 'arithmetic.c', as shown below. Current R-patched seems to build fine, and I've built previous R-devels from source fairly often in the past-- though I have no understanding whatsoever of what's going on. FWIW the only changes

Dear all, I was trying to use the R swig wrapper with R 2.7 and shogun ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't even compile and even after patching then though compiling - crashes... So I asked on swig-users/swig-devel CC'ing the potential R maintainer but I never received a reply. I now wonder if anyone here could help or would be willing to maintain

Hi, I want to make use of some C routines from other packages to write extensions in C. In "Writing R Extensions", it says there is an experimental interface to support this in (or from ?) R 2.4.0. I had a dummy library containing src/dummy.cpp and R/zzz.R: ====== src/dummy.cpp ==== #include <R.h> #include <Rinternals.h> #include <R_ext/Rdynload.h>

On 20 December 2016 at 17:40, Martin Maechler wrote: | >>>>> Steve Bronder <sbronder at stevebronder.com> | >>>>> on Tue, 20 Dec 2016 01:34:31 -0500 writes: | | > Thanks Henrik this is very helpful! I will try this out on our tests and | > see if gcDLLs() has a positive effect. | | > mlr currently has tests broken down by learner type

And remove the cast on the return value of R_GETCCallable. And check that your function is found before using it. #include <R.h> #include <Rinternals.h> #include <R_ext/Rdynload.h> void bdsmatrix_prod4(int nrow, int nblock, int *bsize, double *bmat, double *rmat, int nfrail, double *y) { DL_FUNC fun = NULL; if (fun==NULL)

I am trying to build a C language DLL and it works well with i386 but when I compile with it substituted by x64, like the FAQ page says, the result is an error message: C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl: file not recognized : File format not recognized collect2: ld returned 1 exit status How can I solve this? The problem is with R 2-14.0 and 2-13.0 The complete source code is /* * myfun.c