On 30 Aug 2012, at 16:26, Simon Urbanek <[email protected]> wrote:

> 
> On Aug 30, 2012, at 11:19 AM, Federico Calboli <[email protected]> 
> wrote:
> 
>> On 22 Aug 2012, at 15:12, Simon Urbanek <[email protected]> wrote:
>> 
>>> 
>>> On Aug 22, 2012, at 6:34 AM, Federico Calboli <[email protected]> 
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I used to be able to use the Fortran binaries provided by Simon for both R 
>>>> and Julia, but alas this will not be possible anymore:
>>>> 
>>>> "The problem is not BLAS, but your version of gfortran. Mac provides a 
>>>> built-in system blas, so it is not required to build our own. However, 
>>>> "checking for Fortran 77 name-mangling scheme... unknown" is a problem. It 
>>>> appears that the R version of gfortran is too old to build arpack (a quick 
>>>> google search reveals that gfortran older than 4.4 won't build code 
>>>> properly on 64 bit -- yours is 4.2.3) ."
>>>> 
>>>> I could install the GFortran from here: 
>>>> http://gcc.gnu.org/wiki/GFortranBinaries#MacOS. but (1) they will 
>>>> overwrite /usr/local/bin/gfortran (with a symlink) and (2) I don't know if 
>>>> it will work for R.
>>>> 
>>>> So, will the GCC binary work for R, or is it going to be utter PITA?  I'm 
>>>> on 10.8, Xcode 4.4.1 + CLI add-ons and all the other bells and whistles.
>>>> 
>>> 
>>> They won't work with CRAN R binaries because they don't use Apple 
>>> driver-drivers (i.e. they don't support -arch etc.)*. If you compile R from 
>>> sources, you can use any Fortran binary you want - it will be tied to your 
>>> particular runtime (and you can't use -arch).
>> 
>> I use the CRAN R binary and CRAN binary packages
>>> 
>>> BTW: The FSF Fortran installs in /usr/local/gfortran so it can peacefully 
>>> co-exist with out CRAN Fortran -- even in our Fortran gfortran is just a 
>>> symlink to gfortran-4.2 so you can easily restore it with
>>> sudo ls -sfn gfortran-4.2 /usr/local/bin/gfortran
>>> if you wish.
>> 
>> Given the above, can I leave gfortran to point to the GCC fortran?
> 
> Not for CRAN binary unless you do sed 's:gfortran -arch:gfortran-4.2 -arch:g' 
> on both Makeconf files …

are you saying the binaries (R + whatever libraries I install) using fortran 
will not work with GCC fortran?  I am confused.

> 
>> if I do not, julia throws a hissy fit every time I compile it,
> 
> Can't you just set FC and F77 to gfortran-4.2 when configuring Julia?

It used to be possible (I did successfully build julia on Lion with the R 
gfortran add on for Lion), though now I am on ML and julia has a fit trying to 
build arpack with a fortran < 4.4.  As I posted above from the julia dev 
conversation I started:

"The problem is not BLAS, but your version of gfortran. Mac provides a built-in 
system blas, so it is not required to build our own. However, "checking for 
Fortran 77 name-mangling scheme... unknown" is a problem. It appears that the R 
version of gfortran is too old to build arpack (a quick google search reveals 
that gfortran older than 4.4 won't build code properly on 64 bit -- yours is 
4.2.3) ."

cheers

F

> 
> 
>> though I use and need R *much more than julia*, so I'd like to avoid R 
>> binaries of any sort having a hissy fit if gfortran points to something else 
>> than gfortran-4.2.  Between R and julia I'm with R.
>> 
> 
> Binaries will be fine, but compiling won't work (because FSF gfortran doesn't 
> understand Apple flags).
> 
> Cheers,
> Simon
> 
> 
> 
>> Cheers
>> 
>> Federico
>> 
>> 
>> 
>>> Cheers,
>>> Simon
>>> 
>>> --- for advanced users only - if you have no idea what I'm talking about, 
>>> don't do it ---
>>> 
>>> * - in theory you can use the Apple driver-driver of our Fortran to drive 
>>> FSF-build Fortran. For example if you take the CRAN Fortran then renaming 
>>> your FSF Fortran to i686-apple-darwin8-gfortran-4.2 and putting our driver 
>>> instead of gfortran then you may have some luck using CRAN R with your FSF 
>>> Fortran (obviously, -arch ppc won't work but fewer people care now ;)). 
>>> There are some potential issues, though, for example the FSF binaries use 
>>> purely dynamic setup so anything you compile can only be used on your 
>>> machine. Also in theory you can have runtime version mismatch issues (two 
>>> different versions of gfortran and gcc runtimes) - so your mileage may vary.
>>> 
>>> 
>>>> BW
>>>> 
>>>> F
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Federico C. F. Calboli
>>>> Neuroepidemiology and Ageing Research
>>>> Imperial College, St. Mary's Campus
>>>> Norfolk Place, London W2 1PG
>>>> 
>>>> Tel +44 (0)20 75941602   Fax +44 (0)20 75943193
>>>> 
>>>> f.calboli [.a.t] imperial.ac.uk
>>>> f.calboli [.a.t] gmail.com
>>>> 
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> [email protected]
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>> 
>>>> 
>>> 
>> 
>> --
>> Federico C. F. Calboli
>> Neuroepidemiology and Ageing Research
>> Imperial College, St. Mary's Campus
>> Norfolk Place, London W2 1PG
>> 
>> Tel +44 (0)20 75941602   Fax +44 (0)20 75943193
>> 
>> f.calboli [.a.t] imperial.ac.uk
>> f.calboli [.a.t] gmail.com
>> 
>> 
> 

--
Federico C. F. Calboli
Neuroepidemiology and Ageing Research
Imperial College, St. Mary's Campus
Norfolk Place, London W2 1PG

Tel +44 (0)20 75941602   Fax +44 (0)20 75943193

f.calboli [.a.t] imperial.ac.uk
f.calboli [.a.t] gmail.com

_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Reply via email to