similar to: building R from source on fedora using shared library option

Regarding the previous problem with setting up r-devel in Linux Mint 17.1 64-bit, I deleted all the r-devel files I previously had, and then I did the check out to the '~/svn/r-devel' directory originally mentioned by by Dirk on https://stat.ethz.ch/pipermail/r-sig-debian/2012-August/001935.html, instead of the customised location I previously chose: '~/SVN/R-devel/trunk' and

All of my attempts to build R 3.5.0 from sources under Ubuntu 18.04 have failed, and I cannot figure out what I am doing wrong. I have tried may things, including : export LDFLAGS="$LDFLAGS -fPIC" export CXXFLAGS="$CXXFLAGS -fPIC" export CFLAGS="$CFLAGS -fPIC" ./configure --enable-R-shlib --prefix=/usr/lib/R/3.5.0 #### Configure completes normally without errors or

Dear list, This is my first time trying to set up the development version of R (R-devel ) in my local machine to test some packages before submitting them to CRAN. I'm using Linux Mint 17.1 64-bit, which is an Ubuntu-based distro. However, I'm not able to correctly set up r-devel, apparently due to a problem with enabling the shared library support. I run the first script given by Dirk

I am trying to build R on a Centos server without admin privileges (or support), so I can call R functions from NetLogo models (via the NetLogo R extension or possibly Rserve), but I'm getting stuck near the end of make. Any suggestions? Here's the setup... $ R_SHELL=/bin/sh $ R_HOME=~/R-devel $ cd $R_HOME; ./configure; make returns ... begin installing recommended package MASS

I tried to compile R-beta_2010-10-02_r53128 on FreeBSD 9.0-CURRENT (amd64) with gcc-4.4.5 and it fails: ----------------------------------------- gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I../../src/extra -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c sysutils.c -o sysutils.o sysutils.c: In function

I'm trying to build R 2.10.1 on a Sun Blade 1000 running Solaris 10 (03/05 release). I've installed iconv 1.13.1 and used: CPPFLAGS="-I /export/home/drkirkby/sage-4.3.3.alpha0/local/include" (which is where iconv is) LDFLAGS= -R/export/home/drkirkby/sage-4.3.3.alpha0/local/lib -L/export/home/drkirkby/sage-4.3.3.alpha0/local/lib The build of R fails as below. gcc

> On 18 May 2016, at 18:54 , Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >> Yes, the nightly build is broken in a similar, but different way. See below. >> Both seem to be readline related, so Frederick Eaton's patches, which Martin committed yesterday are the likely culprit. I had actually tested them and things seemed to work, but it was on a

Spoke too soon, both systems now build, but neither has the original bugs fixed.... (Incidentally, I realized why the ctl-R...ctl-C bug never bit me: The emacs habit is to exit isearch with ctl-G and that works flawlessly.) -pd > On 18 May 2016, at 22:40 , peter dalgaard <pdalgd at gmail.com> wrote: > > Ah, got it. For some ancient reason config.site on that machine had >

Ah, got it. For some ancient reason config.site on that machine had LDFLAGS=-L/usr/X11R6/lib in config.site, and that prevented configure from inserting -L /usr/local/lib, so linked /usr/lib/libreadline.dylib, which is the Apple-supplied one, which possibly is really libedit... -p > On 18 May 2016, at 22:01 , peter dalgaard <pdalgd at gmail.com> wrote: > > gcc

>>>>> <frederik at ofb.net> >>>>> on Wed, 18 May 2016 15:03:31 -0700 writes: > Readline <= 6.2 shouldn't require the SIGWINCH patch, so > if older versions have trouble finding rl_resize_terminal > then you could wrap a macro around that part. I find python related patches that use #ifdef HAVE_RL_RESIZE_TERMINAL so they must

Yes, the nightly build is broken in a similar, but different way. See below. Both seem to be readline related, so Frederick Eaton's patches, which Martin committed yesterday are the likely culprit. I had actually tested them and things seemed to work, but it was on a different machine and not a completely clean build. -pd ..... ranlib: file: libR.a(printf.o) has no symbols gcc

Dear All, I am trying to compile R-3.0 on Cray xe6 (HLRS) HERMIT, no success so far. Here is my experience: I use this to configure and make R: CC="cc" \ CXX="CC" \ F77="ftn" \ FC="ftn" \ CPPFLAGS="-I$PREFIX/include" \ LDFLAGS="-L$PREFIX/lib${LIBDIRSUFFIX}" \ ./configure --prefix=$PREFIX \ --exec-prefix=$PREFIX \ --bindir=$PREFIX/bin \

Readline <= 6.2 shouldn't require the SIGWINCH patch, so if older versions have trouble finding rl_resize_terminal then you could wrap a macro around that part. The isearch C-c bug has existed forever, according to Chet Ramey. Yes, I had to retrain myself to use C-g to exit isearch but it's confusing. It would be nice to fix this C-c bug on older versions too, but my solution used some

Hello R Help, I am attempting to install/build a 64-bit version of R to hopefully resolve some memory.limit problems for a user who is running a simulation. The 'configure' runs fine and the compilation (make) runs fine until the very last part (see below). I have libiconv in /usr/local/lib (no sure why I am getting the referencing error). The config.site file is attached. ANY HELP YOU

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

Dear Samba-experts: we migrated from Samba 3.6 to 4.18 and everything works well. But there are two problems where I need some expert-help: We are using a daemon that is running on our AD-server. It accepts connections from remote machines and changes the passwords of certain users. Calling system("smbpasswd") from within that daemon would be too slow so the daemon calls

We have a solaris/sparc machine that has been running an old version of R-devel: Version 2.2.0 Under development (unstable) (2005-06-04 r34577) which was built as m64 from sources. Attempting to upgrade to 2.4.0 the configure step goes ok, but I'm getting early on from make: > gcc -m64 -L/opt/sfw/lib/sparcv9 -L/usr/lib/sparcv9 > -L/usr/openwin/lib/sparcv9 -L/usr/local/lib -o

> Yes, the nightly build is broken in a similar, but different way. See below. > Both seem to be readline related, so Frederick Eaton's patches, which Martin committed yesterday are the likely culprit. I had actually tested them and things seemed to work, but it was on a different machine and not a completely clean build. Indeed a problem. I'm pretty sure that RL_UNSETSTATE()

Hi, I've upgraded our server to the latest R version, everything went ok until I wanted to install RServe for our java clients. RServe needs the shared library which can be compiled using configure --enable-R-shlib. All went ok but after running make I got this error: gcc -shared -L/usr/local/lib64 -o libR.so Rembedded.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o

Hi, I've been trying to get a shared library version of the R package(version 2.12.1) installed on a CentOS 5 system. (It installs fine without but other packages demand shared libs - namely Rapache). I've tried this with yum but don't know of any flags to set to tell it to installl with shared libs enabled. I then tried a local R install as non-root with source packages: after