Skip to content

XCode / gcc / R compatibility issues on Yosemite with XCode 7 and on El Capitan

8 messages · Jenny Brown, Simon Urbanek, Brian Ripley +1 more

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

Cheers,
Simon
#
On 08/10/2015 02:37, Simon Urbanek wrote:
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.

  
    
4 days later
#
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 <ripley at stats.ox.ac.uk>
wrote:

  
  
#
On Oct 12, 2015, at 4:22 PM, Jenny Brown <jennybrown8 at gmail.com> wrote:

            
It means you're not using the Fortran we use (as I said below) - see
http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2

Cheers,
Simon
#
On 13/10/2015 14:36, Simon Urbanek wrote:
Also, you do not need to modify etc/Makeconf ... the manual says

'The default compilers specified in 
/Library/Frameworks/R.framework/Resources/etc/Makeconf depend on the 
version of OS X under which R was installed, and are appropriate to the 
latest version of the command-line tools for that version of OS X. The 
settings can be changed, either by editing that file or in a file such 
as ~/.R/Makevars (see the next section).'

I have in ~/.R/Makevars on my laptop

F77 = /usr/local/gfortran/bin/gfortran
FC = /usr/local/gfortran/bin/gfortran
FLIBS =  -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin14/5.2.0 
-L/usr/local/gfortran/lib -lgfortran -lquadmath -lm

  
    
#
This is Coudert?s gfortran, I presume?
Can it be used together with R binary provided by CRAN and Simon?
Or would one have to recompile R from scratch using Coudert?s gfortran?

Berend
#
On 13/10/2015 16:07, Berend Hasselman wrote:
Yes (but that was only meant as an illustration of what can be done).
It can.  The CRAN R binary is self-contained (it contains libgfortran 
etc in R_HOME/lib).  You can use any Fortran compiler with it to compile 
a Fortran-using package.  (There might be problems with finding the 
runtime components such as libgfortran.dylib from 
/usr/local/gfortran/lib, but this seems usually to just work and the way 
we use the OS X linker the absolute paths are captured at link time.)