[R-SIG-Mac] Problems to install a package

Tue Aug 4 09:57:22 CEST 2015

> 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
It is not clear that you can mix & match the two gfortran versions
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

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. 

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.)

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
>> 
> 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com