Some further digging in the MacPorts fora suggests that gmp is the real culprit, but I'm not through digging yet. Compiling gcc 4.8.5 from source using the binaries of gmp-5.1.3 et al. from r.research.att.com dies with a "gfortran not working" message caused by the familiar f951 illegal instruction error. Replacing with 6.0.0 and retrying "make" didn't help nor did using gmp-6.0.0a compiled locally. However, starting all over after "make distclean" actually produced a functioning gfortran with gmp-6.0.0a. (Thus, it is possible that it would have worked with the binary of 6.0.0 too, if I had tried a clean build.)
(Building gcc/gfortran from scratch literally takes hours on the aging iMac, so experimenting is, um, inconvenient... In comparison, building gmp was a piece of cake, so if that suffices, it would be great.) I'll see if I can dig deeper tomorrow. -pd > On 03 Aug 2015, at 15:57 , peter dalgaard <[email protected]> wrote: > > > On 03 Aug 2015, at 15:10 , Berend Hasselman <[email protected]> wrote: > >> >>> On 03-08-2015, at 13:59, 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. >>> >> >> Good to know that. >> >>> So I think the finger is pointing at the binaries on >>> r.research.att.com/libs. >> >> Indeed as was confirmed by Simon last year here >> https://stat.ethz.ch/pipermail/r-sig-mac/2014-May/010895.html >> I can use the binary of r.research.att.com/libs since I now have a more >> modern Mac with an i5 cpu. >> >> I did some searching and found the following: >> >> http://coudert.name/software.html >> >> and https://gcc.gnu.org/wiki/GFortranBinaries#MacOS >> >> Might be a good idea to try these versions of gfortran too on a C2D. > > Yes. However, I'll have to worry about overwriting and possibly breaking my > build environment with 3.2.2 coming out next Friday (Simon's binary package > rather carefully installs gfortran-4.8, but not gfortran, I believe. Won't > know about the others until I try them.). So, not on this machine. > >> Maybe the CRAN R could be built with one of these gfortran binaries >> avoiding the need to compile an R provided gfortran and distributed on >> r.research.att.com/libs. > > I haven't seen evidence that there is a problem with the CRAN binaries of > anything and we still need to provide gfortran somehow for people who need to > build from source. What we could try is to compile 4.8 on a C2D or > cross-compile it for that architecture. I think that the latter is doable, > but I don't recall the details (gcc --target ?). > > -pd > >> But that is beyond me and I have no idea about possible issues doing it. >> >> Berend >> > > -- > 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] -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: [email protected] Priv: [email protected] _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
