search for: g_cntrlifi

Full_Name: Jeet Sukumaran Version: 2.9.0 OS: OS X / Rocks 5.1 Submission from: (NULL) (66.45.136.241) If R is configured using the "--with=x=no" option, then the make fails with the following error: make[4]: Entering directory `/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules/vfonts' gcc -std=gnu99 -I. -I../../../src/include -I../../../src/include -I/usr/local/include

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

Hi, I just try to compile R (1.1.1) for MacOS X (using the --without-X option as X stuff won't work here) It seems that there are some problems with 'shared libraries'. './configure' printed: checking how to deal with shared libraries... /usr/X11R6/bin/xmkmf: command not found: imake [56] 'make' ran into trouble with this: cc -I. -I../../src/include

Dear "R"-Team, we had some problem to install R-2.7.2 on HP-UX 11.11 on PA-Risc platform. 1.) i load down the Software and made a extract of the tar-file in a specific Directory. 2.) i follow the instructions on the INSTALL file: ./configure 3.) during "configure" we got a error message see below: checking for history_truncate_file... no configure: error:

> 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()

> 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

I have tried compiling R on a SGI 6.0 and got the following: cc -o ../../bin/R.X11 apply.o arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o colors.o complex.o context.o cov.o cum.o debug.o devPS.o devPicTeX.o deparse.o deriv.o devices.o dotcode.o dstruct.o duplicate.o envir.o errors.o eval.o format.o fourier.o g_her_glyph.o g_fontdb.o g_cntrlify.o g_alab_her.o gram.o

Full_Name: Albrecht Gebhardt Version: 0.99.0 OS: alpha, osf4.0 Submission from: (NULL) (143.205.180.40) DEC cc doesn't like c++ style comments // like this one Please use standard cc comments or #if 0 ... #endif A quite large patch follows (I hope it will pass mailing with not too much wrapped lines): --- ./src/main/g_her_glyph.c.dec-cc.patch Mon Feb 7 14:48:10 2000 +++

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 >

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

Hi. Just wanted to let you know I am getting close to packaging R for AIX in 64.bit mode. One comment - the libtool.m4 I see used is quite old. The one I have on my system is 2.4.6, and what I see in R says: I am hoping a new libtool will clean up most of the manual work now needed. # Which release of libtool.m4 was used? macro_version=2.2.6 macro_revision=1.3012 This may be all that is

On our Scientific Linux 6, there is gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17) and later version (a symbolic at HOME to the system directory), export MKL=/home/jhz22/11.3.3.210/mkl export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MKLROOT/lib/intel64 ./configure --prefix=/home/jhz22 LDFLAGS=-L/home/jhz22/lib CPPFLAGS=-I/home/jhz22/include \ --enable-R-shlib --with-lapack \

Dear R-devel, The latest version of R-devel (05-17) is throwing an error for me when building on OS X (v 10.11.4): making Rembedded.d from Rembedded.c making dynload.d from dynload.c making system.d from system.c making sys-unix.d from sys-unix.c making sys-std.d from sys-std.c making X11.d from X11.c clang -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H

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

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

Dear R-developers, I would appreciate any insights over compiling R 3.4 with Intel MKL -- I have been successful until R 3.3.3 but now it stops complaining about pcre though it worked without Intel MKL as follows, ./configure LDFLAGS=-L/genetics/data/software/lib CFLAGS=-fPIC -I/genetics/data/software/include --enable-R-shlib I have used, export MKL_NUM_THREADS=15 export

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

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