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.
XCode / gcc / R compatibility issues on Yosemite with XCode 7 and on El Capitan
8 messages · Jenny Brown, Simon Urbanek, Brian Ripley +1 more
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 Oct 7, 2015, at 10:47 AM, Jenny Brown <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
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 <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
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 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 <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
On Oct 12, 2015, at 4:22 PM, Jenny Brown <jennybrown8 at gmail.com> wrote:
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.
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
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 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 <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[[alternative HTML version deleted]]
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
On 13/10/2015 14:36, Simon Urbanek wrote:
On Oct 12, 2015, at 4:22 PM, Jenny Brown <jennybrown8 at gmail.com> wrote:
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.
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
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
Cheers, Simon
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 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 <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[[alternative HTML version deleted]]
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
On 13 Oct 2015, at 16:14, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: On 13/10/2015 14:36, Simon Urbanek wrote:
On Oct 12, 2015, at 4:22 PM, Jenny Brown <jennybrown8 at gmail.com> wrote:
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.
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
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
Cheers, Simon
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 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 <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[[alternative HTML version deleted]]
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
On 13/10/2015 16:07, Berend Hasselman wrote:
On 13 Oct 2015, at 16:14, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: On 13/10/2015 14:36, Simon Urbanek wrote:
On Oct 12, 2015, at 4:22 PM, Jenny Brown <jennybrown8 at gmail.com> wrote:
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.
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
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?
Yes (but that was only meant as an illustration of what can be done).
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?
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.)
Berend
Cheers, Simon
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 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 <jennybrown8 at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[[alternative HTML version deleted]]
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at 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 at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK