Problems to install a package
On 04/08/2015 08:57, peter dalgaard wrote:
On 03 Aug 2015, at 23:48 , Simon Urbanek <simon.urbanek at r-project.org> wrote: Sorry, I thought it was obvious so I didn't elaborate in more detail - our Mavericks compiler binary (gfortran-4.8) itself is using more advanced instruction set so it doesn't work on older CPUs (C2D as it appears). It's likely something to do with gmp/mpfr since those are the only ones that use hand-coded assembler instructions and they picked the one for the host CRAN machine with is a Mac Pro (Xenon). It doesn't have an effect on the compiled result since the flags govern that - so the compiled packages will work just fine on old hardware. Given that anyone with older hardware should simply be able to use the Fortran from CRAN I didn't think it could spawn such a long thread ;). After all, the underlying GNU Fortran is the same anyway.
Umm, the situation as I see it is this: The R Mavericks binaries "hardcode" gfortran-4.8 in etc/Makeconf Gfortran from CRAN is 4.2.3
The recommended gfortran for the CRAN 'Mavericks' build has always been gfortran 4.8.0: see the R-admin manual.
It is not clear that you can mix & match the two gfortran versions
It does not always work, although as FLIBS is static problems are rare (but usually segfault). And there are packages which gfortran 4.2.3 will not compile.
Users who want to compile Fortran from source therefore get binaries for
gfortran-4.8, gmp, mpfr from r.research.att.com
This combination is broken on C2D machines
AFAICS you only need the binary of gfortran 4.8.0, as the gmp/mpfr libs are statically linked.
Result: confusion (+ for some, a welcome incentive to upgrade...) If the fix can be as simple as editing Makeconf for a different Fortran (F77 and FLIBS entries), we should say so somewhere.
We do, at https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#OS-X (although that was not current on CRAN when I just looked).
Otherwise, I think it might be possible to "unbreak" gfortran-4.8 since the cause of the breakage is known. (I gather that it happens in something as silly as parsing floating constants in Fortran source, which at the very least can hardly be said to be a performance issue.)
As we no longer support multiple sub-architectures on OS X, the Apple drivers are not needed. I would be tempted to move to the binaries provided by Fran?ois-Xavier Coudert via the GCC wiki (also mentioned in the current manual).
Na zdrav?, Peter
Cheers, Simon
On Aug 3, 2015, at 7:59 AM, peter dalgaard <pdalgd at gmail.com> wrote: I have now tried doctoring $RHOME/etc/Makeconf to use a MacPorts build of gfortran-4.8 that I had lying around, and lo and behold: It does source installs of nleqslv, geigen, QZ, rms with no trouble at all. So I think the finger is pointing at the binaries on r.research.att.com/libs. -pd On 03 Aug 2015, at 11:26 , peter dalgaard <pdalgd at gmail.com> wrote:
On 01 Aug 2015, at 11:40 , peter dalgaard <pdalgd at gmail.com> wrote:
On 01 Aug 2015, at 07:34 , Berend Hasselman <bhh at xs4all.nl> wrote:
On 31-07-2015, at 22:14, peter dalgaard <pdalgd at gmail.com> wrote:
On 31 Jul 2015, at 21:36 , Berend Hasselman <bhh at xs4all.nl> wrote:
On 31-07-2015, at 20:46, peter dalgaard <pdalgd at gmail.com> wrote:
On 31 Jul 2015, at 12:33 , Timothy Bates <tim.bates at ed.ac.uk> wrote: This happened for me too: that Intel Core 2 is just too old for the compiler. I used it as a stimulus to buy a new laptop? As a bonus, everything is ~10x faster Best, tim
Hum, well, I wasn't actually planning to switch out my MB Air just now. I'm actually baffled that I haven't bumped into this before. Both my laptop and my office desktop are Core 2 Duo machines (and the latter is the one that builds the R source releases!).
If you use gfortran: which version? If you are not using any floating point then gfortran-4.8 will probably work without problems. I think.
It's 4.2.1 and 4.2.3, it seems. That's for the local builds; for the CRAN binaries, it seems that I just never tried building a package with Fortran in it. Not sure whether I have used any Fortran binaries (is there an easy way to check whether a package contains Fortran?)
But then you are still using the Snow Leopard binaries for R? I don?t know if stuff created with the older gfortran will run with an R built for mavericks.
Those were for local builds, which I suppose will by definition be Yosemite/Mavericks builds (laptop/desktop respectively). The corresponding C compiler is gcc, alias $ gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.4.0 Thread model: posix
Two of my packages: nleqslv and geigen. They could not compile on my previous C2D computer with gfortran-4.8. And another one: QZ. And there are some more. You would also need the Mavericks binaries of R.
The CRAN binaries of nleqslv seem to install, load, and run OK with the Mavericks CRAN binaries. Source build of nleqslv builds, loads, runs with a local build on Yosemite. In both cases, "runs" means that example(nleqslv) and example(testnslv) does something seemingly sensible and do not crash. (Source build with Mavericks/CRAN would obviously fail due to the absence of gfortran-4.8 and I wouldn't even try mixing the two Fortran versions.)
-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
_______________________________________________ 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