On 04/08/2015 08:57, peter dalgaard wrote:
On 03 Aug 2015, at 23:48 , Simon Urbanek <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
On 01 Aug 2015, at 11:40 , peter dalgaard <[email protected]> wrote:
On 01 Aug 2015, at 07:34 , Berend Hasselman <[email protected]> wrote:
On 31-07-2015, at 22:14, peter dalgaard <[email protected]> wrote:
On 31 Jul 2015, at 21:36 , Berend Hasselman <[email protected]> wrote:
On 31-07-2015, at 20:46, peter dalgaard <[email protected]> wrote:
On 31 Jul 2015, at 12:33 , Timothy Bates <[email protected]> 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: [email protected] Priv: [email protected]
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, [email protected]
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
