similar to: R build fails during make when configured with "--with-x=no" (PR#13665)

> 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

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

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 >

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

jeet at ku.edu wrote: >=20 > If R is configured using the "--with=3Dx=3Dno" option, then the make fa= ils with the > following error: ,,,, > make[1]: *** [R] Error 1 > make[1]: Leaving directory `/home/jeet/Scratch/r-build/on-frontend/R-2.= 9.0/src' > make: *** [R] Error 1 >=20 > The problem appears to be with the "src/modules/Makefile".

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

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

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

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

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:

Dear Developers, I'm updating my R installation via svn (currently: Revision 44626). For some time now (sorry don't know the exact revision number) make for R devel yields the following error make[4]: *** Keine Regel vorhanden, um das Target ?../../../src/include/R_ext/GraphicsBase.h?, ben?tigt von ?g_fontdb.o?, zu erstellen. Schluss. (translation: no rule to make target ...

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

Full_Name: Nicolas Delhomme Version: 2.9.0 OS: Linux CentOS release 5.3 kernel 2.6.18-128.el5 arch x86_64 Submission from: (NULL) (194.94.44.4) Hi, The commands I used to compile R2.9.0 on CentOS ./compile --with-x=no make This fails with the following message: make[2]: Leaving directory `/home/delhomme/R-2.9.0/src/modules/vfonts' make[1]: Leaving directory

Hi all, I've encountered a build error with the latest R source (2.8.1). This is a relatively fresh install of OS Leopard (10.5.6), latest developer tools installed, gcc/g++/gfortran version 4.4 installed (via http://hpc.sourceforge.net/, after which I updated the gcc & g++ symlinks to link to the 4.4 versions; gfortran used the 4.4 version without updating the symlink). Ultimately I