[R-SIG-Mac] Fwd: Compiling R-3.1.1 sources under OS X Yosemite
Hi, Has anyone successfully compiled R-3.1.1 sources under OS X Yosemite? If so, could you please pass me the right configure options? I got the following error when I tried to build it. Is something wrong with my gfortran compiler? thanks Qiong gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix gfortran --version gfortran: warning: couldn’t understand kern.osversion ‘14.0.0 GNU Fortran (GCC) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. ./configure SHELL='/bin/bash' r_arch=x86_64 CC=gcc -arch x86_64 -std=gnu99 CXX=g++ -arch x86_64 OBJC=gcc -arc x86_64 F77=gfortran -arch x86_64 FC=gfortran -arch x86_64 --with-system-zlib --with-blas='-framework vecLib' --with-lapack // checking for gcc -arch x86_64 -std=gnu99 option to support OpenMP... unsupported checking how to get verbose linking output from gfortran -arch x86_64... configure: WARNING: compilation failed checking for Fortran 77 libraries of gfortran -arch x86_64... checking how to get verbose linking output from gcc -arch x86_64 -std=gnu99... -v checking for C libraries of gcc -arch x86_64 -std=gnu99... -L/usr/local/lib -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/Users/qiongcai/Codes/r-projects/R-3.1.1': configure: error: cannot compile a simple Fortran program [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Fwd: Compiling R-3.1.1 sources under OS X Yosemite
Hi Amos, Could you please send me the configure scripts for both gcc and llvm? I would like to try both. Thanks a lot. Qiong On Tue, Oct 28, 2014 at 9:32 AM, Amos B. Elberg amos.elb...@gmail.com wrote: It looks like you're trying to use Xcode plus the old gfortran to compile it. I've compiled it successfully with gcc 4.9 and llvm 3.5, installed by the homebrew package manager. If you want to use one of those compilers, I can give you configure scripts that will work. (Also you should change -framework vecLib to -framework Accelerate in Yosemite) On Oct 28, 2014, at 4:24 AM, Qiong Cai qiong@gmail.com wrote: Hi, Has anyone successfully compiled R-3.1.1 sources under OS X Yosemite? If so, could you please pass me the right configure options? I got the following error when I tried to build it. Is something wrong with my gfortran compiler? thanks Qiong gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix gfortran --version gfortran: warning: couldn’t understand kern.osversion ‘14.0.0 GNU Fortran (GCC) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. ./configure SHELL='/bin/bash' r_arch=x86_64 CC=gcc -arch x86_64 -std=gnu99 CXX=g++ -arch x86_64 OBJC=gcc -arc x86_64 F77=gfortran -arch x86_64 FC=gfortran -arch x86_64 --with-system-zlib --with-blas='-framework vecLib' --with-lapack // checking for gcc -arch x86_64 -std=gnu99 option to support OpenMP... unsupported checking how to get verbose linking output from gfortran -arch x86_64... configure: WARNING: compilation failed checking for Fortran 77 libraries of gfortran -arch x86_64... checking how to get verbose linking output from gcc -arch x86_64 -std=gnu99... -v checking for C libraries of gcc -arch x86_64 -std=gnu99... -L/usr/local/lib -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/Users/qiongcai/Codes/r-projects/R-3.1.1': configure: error: cannot compile a simple Fortran program [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Yosemite and R
Dear all, Brian Ripley has brought it my attention that R 3.1.2, due to be released soon, *does* check that X11 is present and prints an informative error message if it isn't. That's a substantial improvement. Thanks, John On Tue, 28 Oct 2014 09:43:53 -0400 John Fox j...@mcmaster.ca wrote: Dear Rich, I've made a similar suggestions before, I believe. It would even help to have tcltk fail less cryptically if X-Windows is unavailable under Mac OS X, suggesting that XQuartz be installed and pointing to the XQuartz website. And it shouldn't be hard to check capabilities()[X11] when tcltk loads. The large majority of Rcmdr problems about which people write me concern this one issue. There are clear, detailed installation instructions on the Rcmdr website but no way for me to insure that people are aware of them. I spent some time trying to find a way to report the absence of X-Windows at Rcmdr start-up, but the dependency on tcltk causes the Rcmdr to fail to load before an informative message can be printed -- a chicken-and-egg problem. Maybe there's a way to do this that I didn't discover. The essential problem here is that naive users don't have an obvious way of avoiding the problem. They install the software and expect it to work. There are similar issues with the system path under Yosemite and with app nap. This leads to repetitious emails to package maintainers and to repetitive questions on the various help lists, etc. That said, I think that there is a good solution for teachers of courses, workshops, etc.: Create -- or point to existing -- clear installation instructions that include installing XQuartz under OS X. The less tractable problem is individual users downloading and installing R from CRAN. Best, John On Tue, 28 Oct 2014 00:03:52 -0400 Richard M. Heiberger r...@temple.edu wrote: I just did a workshop for new R users. the only serious installation problem I saw was Macintosh users and tctlk. From this discussion, I knew to tell both people they needed to download quartz.macosforge.org and indeed that solved it. Is there a place on the package DESCRIPTION file to state that dependency, thus triggering the download and installation of quartz? That would take the responsibility for discovering this need away from the end user? Rich On Thu, Oct 23, 2014 at 2:15 PM, John Fox j...@mcmaster.ca wrote: Dear Simon, I installed Yosemite a couple of days ago and everything seems to work fine so far, including the tcltk demo that caused problems for Peter, and the Rcmdr package, which gives Tcl/Tk a pretty good workout. I first reinstalled XQuartz, as suggested, and I also reinstalled R and updated all packages, though the latter two steps probably weren't necessary. I figured that it would help to hear positive experiences as well as problems. The only issue that I've encountered so far is specific to checking packages under RStudio, which doesn't appear to find pdflatex; OTOH, R CMD check runs fine in a terminal window. I haven't yet tried to resolve this problem. Best, John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Tuesday, October 21, 2014 4:38 PM To: John Fox Cc: Amos B. Elberg; r-sig-mac; Spencer Mass; Ben Clark; peter dalgaard; Marc Schwartz; David Winsemius; Hadley Wickham Subject: Re: [R-SIG-Mac] Yosemite and R I wasn't able to reproduce but I suspect those are all red herrings - there are really no subprocesses involved at all in either case. On Oct 21, 2014, at 4:19 PM, John Fox j...@mcmaster.ca wrote: Dear all, I wonder whether this issue also accounts for the tcltk problems that have been reported. (I haven't yet upgraded to Yosemite myself, hoping to wait for the wrinkles to be ironed out, though I'll likely do so shortly if only to see what happens.) Best, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Amos B. Elberg Sent: Tuesday, October 21, 2014 12:40 PM To: David Winsemius; Hadley Wickham Cc: r-sig-mac; Spencer Mass Subject: Re: [R-SIG-Mac] Yosemite and R If the full environment isnt getting passed to R-spawned sub- processes, that might explain an error Ive been having since the update: when R is launched from the command line, calls that should create an X11 window in the background fail unless an X11 window has already been created with the width and height specified: plot(rnorm(100)) Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, : invalid 'width' or 'height' X11() Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, : invalid 'width' or 'height' X11(width = 5, height = 5)
[R-SIG-Mac] Command Line Quartz Device in Yosemite
I’ve been using command line R fairly successfully under Yosemite so far and have only run into a few issues, mostly related to the quartz device. First, it seems that under Yosemite, the default device is now x11 instead of quartz. I found this with the exact same pkg install of R that I was using in Mavericks, which defaulted to quartz. Installing the latest Mavericks build (3.1.1) results in the same behavior. Even when running R_DEFAULT_DEVICE=quartz R”, the default device still ends up being x11. The quartz device can still be created manually with a call to quartz(). Does anyone else have this same problem? Second, the menus for the quartz device created through the command line have gotten even stranger under Yosemite. With the current version there are actually two (!) Apple menus displayed, which looks quite odd: https://dl.dropboxusercontent.com/u/21171664/R_Two_Apple_Menus.png About a year ago I submitted a patch with made the command line quartz device act much more like a normal OS X application: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15438#c1 This patch continues to work well under Yosemite, and does not display the double Apple menu problem. However, it seems to have currently fallen off the radar. Given the even stranger behavior of the current code under Yosemite, perhaps evaluation of my patch could be given a higher priority? If it would help I can provide updated files which are drop-in replacements for the current R trunk. Cheers, Colin ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
