Thank you to both of you. I believe my issue is solved by using the binary distribution of gfortran libraries, as it was dynamic linking that was causing me the most headache. And that seems to solve that.
I still have to modify the etc/Makeconf file to use the right directory for -L and the right library name for gfortran .... it comes written as gfortran-4.8 in the Makeconf but that gives a not-found on my system. I'm not entirely clear on when the Makeconf is initially written during a binary install of R. But it does seem that I can adjust the lines related to fortran and get it to work for compiling my source packages. Thanks! On Thu, Oct 8, 2015 at 1:33 AM, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote: > On 08/10/2015 02:37, Simon Urbanek wrote: > >> Jenny, >> >> I suspect you may not have the correct information. The CRAN Mavericks >> binary of R is not built with gcc, it's actually build using Apple clang >> and we're neither using nor requiring homebrew, so most of what you are >> describing doesn't make sense to me. I have tested Xcode 7 with the >> gfortran-4.8 we supply and it works just fine on 10.11 (tested on Hmisc). I >> have only 10.6, 10.9 and 10.11 so I can't check 10.10, but I would >> certainly recommend building on 10.9 with Xcode 6 for compatibility (that's >> what we do for CRAN). If you don't care about binary compatibility then >> Xcode 7 on 10.11 is fine (FWIW Hmisc package compiled on 10.11 actually >> works for me on 10.9 so it could even be that you may get away with using >> 10.11 if you don't use system dependencies with higher versions). >> > > It also works for me on 10.10. If the 'Command Line Tools OS X 10 for > Xcode 7' Apple package is installed on 10.10 (specifically file > http://adcdownload.apple.com/Developer_Tools/Command_Line_Tools_OS_X_10.10_for_Xcode_7/Command_Line_Tools_OS_X_10.10_for_Xcode_7.dmg), > it installs > > % clang --version > Apple LLVM version 7.0.0 (clang-700.0.74) > Target: x86_64-apple-darwin14.5.0 > > hence targets OS X 10.10 aka Darwin 14. My 10.10 machine does not have > Xcode installed, only the CLT: you do not need Xcode's SDKs to compile R > nor any CRAN package. (You do need Xcode to compile R.app.) > > For Fortran on Yosemite/El Capitan I use the gfortran 5.2 build at the > sites given in the current R-admin manual ('Other builds of gfortran are > available: see https://gcc.gnu.org/wiki/GFortranBinaries and > http://coudert.name/software.html'). My recollection is that the > 'gfortran-4.8 for Mavericks' on r.research.att.com does compile all but > one of the CRAN packages on Yosemite (SWATmodel which compiles executables > from Fortran code), in some cases with warnings. > > Note that any recent(ish) build of gfortran will have dynamic libgfortran > and libquadmath libraries, and installations of most Fortran-using packages > will link to these. So you either need to install those libraries on all > the machines or arrange for the packages you distribute to point to the > copies in the CRAN build (in R_HOME/lib) as is done for the CRAN binary > packages. (I believe they are post-processed by > https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Simon/packages/1.fixr > .) My recollection is that a very few packages also link to libgcc_s, also > in R_HOME/lib. > > > > Cheers, >> Simon >> >> >> On Oct 7, 2015, at 10:47 AM, Jenny Brown <jennybro...@gmail.com> wrote: >>> >>> I am maintaining R installations and packages for a large number of OS X >>> machines. A recent change from Apple is making the R installation more >>> awkward, and I'm trying to determine the best path forward with minimal >>> maintenance headaches. >>> >>> >>> Recently, XCode 7's release on Yosemite 10.10 broke compilation of "brew >>> install --with-fortran gcc48" which is a pre-requisite for compiling >>> third >>> party R packages that use fortran. (XCode 7 eliminates the 10.9 and >>> 10.10 >>> SDKs and only provides 10.11 which is El Capitan's... so even though >>> XCode >>> 7 installs on Yosemite, it can not build for Yosemite, which causes gcc >>> trouble. Lots of opensource devs are commenting on this on various >>> projects.) >>> >>> It appears that the binary installs of R for OS X (3.1 through 3.2.2) >>> were >>> all built against gcc 4.8. I've discovered that gcc 5.2 builds properly >>> on >>> Yosemite, even with XCode 7, and R can be compiled with gcc 5.2. >>> >>> However, even the latest R (3.2.2) on cran.rstudio.com appears to be >>> built >>> by default with gcc 4.8 -- are there plans to move to gcc 5.2? >>> Presumably >>> the breakage I'm seeing where gcc 4.8 can't use the xcode 7 10.11 SDK >>> would >>> also occur on El Capitan, so gcc 5.2 would be a necessary upgrade there >>> too. >>> >>> Right now my choices for getting R to work with my third-party fortran >>> packages appear to be: manually downgrade xcode to 6.4 for Yosemite; or, >>> maintain my own compilation of R against gcc 5.2, for each of Yosemite >>> and >>> El Capitan. Both have their downsides, and I hope to be able to return >>> to >>> the normal public binary R distribution sooner rather than later. >>> >>> What's on the roadmap for upcoming upgrades and compatibility? Thanks. >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-SIG-Mac mailing list >>> R-SIG-Mac@r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>> >>> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac@r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford > 1 South Parks Road, Oxford OX1 3TG, UK > > > _______________________________________________ > 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
