On Mar 21, 2011, at 9:19 AM, Prof Brian Ripley wrote: > On Sun, 20 Mar 2011, Berend Hasselman wrote: > >> >> On 20-03-2011, at 20:49, Tracy Lightcap wrote: >> >>> Simon: >>> >>> I sent part of your post to Steve Jobs and he wrote back (!). Here's >>> what he said. Is he still dancing around the issue about gfortran? >>> >> >> I would say yes. >> Can Apple guarantee that Intel Fortran and Apple's C compiler coexist and >> cooperate flawlessly? >> Anyone using R on the Mac and wishing to compile R and/or develop packages >> with some Fortran would have to get the Intel Fortran compiler according to >> Job's recommendation. If I'm correct, Intel's compiler are not cheap. Most >> of us wouldn't want to spend that kind of money. >> >> If and when a transition is necessary, then we'll just have to hope that >> Simon finds a way of making gfortran usable in the new setup. >> >> As long as we can use Xcode 3, there shouldn't be a problem. >> >> To be honest, I don't think Apple really cares about things such as R. > >> The ultimate alternative would be to ditch Mac OS X and change to something >> else. > > I don't think that is necessary. Provided you have a reasonable C compiler > to start from, you can always build and install your own GNU toolchain and > build R with that. And that is what fink, MacPorts, ... do, as I understand > it. Simon rightly warns that they give you other things you do not want, but > that's not stopping a simple solution. >
I'm more worried about the things they break ;). Fink and MacPorts software does not inter-operate well with anything outside and the quality of the ports is dubious (and new OS support lags quite a bit). But this is mostly irrelevant to the compilers - we have had a setup to use GNU build of gfortran before (including the use of Apple's drivers to support Apple-style flags like -arch). The real issue is the mess with run-rime libraries, for example. We can't use static libraries because we load multiple shared objects into one binary, so the implication is that there will be different dylib versions around (system, GNU compiler etc.) - causing potential trouble. > There are two relevant things which I know of which are special to the Apple > toolchain. > > 1) Support (or level of support) for Objective C(++). That's not an issue > for R nor for any of the packages: it is for R.app. However, the latter is > compiled separately and 'should' link to a libR.dylib compiled under a > non-Apple toolchain. > Quartz Cocoa back-end in R is objective C, but that should still be inter-operable. R.app can be compiled with clang and linked to R regardless of the way R was compiled. > 2) The ability to make 'fat binaries' by things like > > gcc -arch i386 -arch x86_64 > > and more generally to select the architecture in this way. However, we > hardly use fat binaries in R (only Rscript, AFAIR) and once ppc is no longer > supported, the standard -m32 and -m64 flags will work with the standard GCC > toolchain. > This is just a matter of the compiler driver by Apple which selects the proper compiler/cross-compiler, adds -m32 or -m64 and uses lipo to create the final result. We can use that driver even with GNU gcc. > I would be staggered if the task of producing a suitable toolchain for Mac OS > X was 50% of the work needed for Windows. But of course someone would need > to be prepared to do it, and I suspect that the volume of Mac users of R is > less than 10% of that for Windows. > The situation is not unlike on Windows -- so far we were able to re-use the canonical tools for the OS, but that may not longer be possible. Maintaining tools outside of the canonical OS tools is always possible, but increases the risk of incompatibilities. This is especially true for external parts (libraries) that we do not supply - they are currently built with Apple's tools so it's fairly safe to use them. If we have to switch to a different toolset, it may lead to issues. The bottom line is that there are options, we just can't rely on the canonical OS tools anymore. Before Apple's gcc 4.2 branch we did not have native (Xcode) Fortran and there were constantly some issues. Then gcc 4.2 came along and we had a fairly smooth sailing so far. So it just means more work for me, that's all ;). Cheers, Simon BTW: GNU doesn't make things easier, either. Most rect GCCs rely on very weird dependencies that are not exactly written in a portable way and a pain to compile... >> >> Apologies for the rant but I really do feel that Apple is behaving stupidly >> and shortsightedly in this case. >> >> Berend >> >>> Tracy >>> >>> Begin forwarded message: >>> >>>> From: Steve Jobs <[email protected]> >>>> Date: March 20, 2011 3:29:01 PM EDT >>>> To: "[email protected]" <[email protected]> >>>> Subject: Fwd: R and your stance on Fortran >>>> >>>> >>>>> >>>>> Xcode 4 (and our general evolution away from gcc to clang/LLVM) >>>>> does not change the availability of Fortran (or the R programming >>>>> language) on the Mac. GNU will continue to distribute GCC (and >>>>> gfortran) for the Mac and code generated by that compiler will >>>>> continue to integrate with code built with our modern clang/LLVM >>>>> tools. (As an aside, our recommended solution for Fortran on the >>>>> Mac has long been the Intel Fortran compiler -- it generates much >>>>> better performing code than GCC's Fortran). >>>>> >>>>>> >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> Resent-From: [email protected] >>>>>>> From: Tracy Lightcap <[email protected]> >>>>>>> Date: March 17, 2011 9:38:32 AM PDT >>>>>>> Resent-To: [email protected] >>>>>>> To: [email protected] >>>>>>> Subject: R and your stance on Fortran >>>>>>> >>>>>>> Steve: >>>>>>> >>>>>>> I use R as my main stats engine, as do a lot of Mac users; >>>>>>> there's even a list serv for Mac R users. Now I read this in one >>>>>>> of the posts there: >>>>>>> >>>>>>> As Brian (Ripley, professor of applied statistics, Oxford) >>>>>>> pointed out, R doesn't care. The only annoying part for me as a >>>>>>> Mac binary maintainer is that it means Apple has abandoned the >>>>>>> only branch that supported Fortran back-end, so in the future we >>>>>>> will not be able to provide native Fortran for Xcode. This has >>>>>>> been known for a while and Apple's stance is that they don't care >>>>>>> about Fortran, so in some (but not immediate) future we may be >>>>>>> back to the mess of mixing compilers. >>>>>>> >>>>>>> Note that LLVM and clang don't really have any real benefits for >>>>>>> the R users so far. Tests suggest that they make some parts >>>>>>> slower and we could not measure any overall benefit (unlike let's >>>>>>> say on arm), so people were not rushing to llvm/clang so far. >>>>>>> Apple's move to llvm/clang is really based on a political >>>>>>> decision, not a technical one. The only benefit I see so far is >>>>>>> what Brian mentioned as well that some people will have to >>>>>>> realize that gcc is not the standard and can test on other >>>>>>> compilers to find their bugs. >>>>>>> >>>>>>> Cheers, >>>>>>> Simon (Urbanek, statistics research, AT&T Labs) >>>>>>> >>>>>>> Is it really true that Apple, a company that is alive today >>>>>>> largely due to its inroads in education, is willing to put the >>>>>>> distribution of the most rapidly growing statistics engine used >>>>>>> by academics in jeopardy because "∑ Apple's stance is that they >>>>>>> don't care about Fortran ∑"? R has recently been adopted as the >>>>>>> official language by the Interuniversity Consortium for Political >>>>>>> and Social Research at the University of Michigan, the biggest >>>>>>> trainer of social science grad students in the country. It is >>>>>>> being adopted by universities and colleges, governments, and >>>>>>> research institutions at a staggering pace (the price is right, >>>>>>> you know). That the use of this extremely useful and powerful >>>>>>> application on the Macs in education should be put at risk by a >>>>>>> simple reluctance to not accommodate Fortran is not just unwise; >>>>>>> it's just plain silly. >>>>>>> >>>>>>> Is Simon right? If he is, fix it. Now. >>>>>>> >>>>>>> Tracy Lightcap >>>>>>> Professor and Chair >>>>>>> Department of Political Science >>>>>>> LaGrange College >>>>>>> 601 Broad St. >>>>>>> LaGrange GA 30240-2999 >>>>>>> (O) [email protected] (H) [email protected] >>>>>>> 706.880.8226 >>>>>>> www.lagrange.edu/academics/political-science/faculty/tlightcap.aspx >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >>> Tracy Lightcap >>> Professor and Chair >>> Department of Political Science >>> LaGrange College >>> 601 Broad St. >>> LaGrange GA 30240-2999 >>> (O) [email protected] (H) [email protected] >>> 706.880.8226 >>> www.lagrange.edu/academics/political-science/faculty/tlightcap.aspx >>> >>> >>> >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-SIG-Mac mailing list >>> [email protected] >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> _______________________________________________ >> R-SIG-Mac mailing list >> [email protected] >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> > > -- > Brian D. Ripley, [email protected] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 > 272595_______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
