On Aug 24, 2005, at 11:09 AM, Simon Urbanek wrote:
> On Aug 22, 2005, at 12:44 AM, Cyrus Harmon wrote:
>
>
>> Ok, but, sense or not, the result of the failing test is that the
>> the use_lapack is turned off and we don't link against the
>> external lapack. Is this the desired behavior? If so there's
>> probably a better solution than just breaking the build.
>>
>
> ... it's not "breaking the build" - because if you go ahead ignoring
> the test, the build will be broken anyway, only silently - all of the
> affected vecLib functions will simply segfault - they just don't work
> with gfortran.
>
> I have a prototype work-around for this by creating wrapper functions
> and calling cblas_xx instead and I'm testing it right now, but it's
> ugly and will make it to R-devel only if it doesn't break anything
> else.
>
> I just repeat what I've said here already: unless you desperately
> need 64-bit R there is no real benefit from using gcc4, because it's
> still very instable (gfortran segfaults even on simple examples) and
> unreliable (gfortran is even slower than g77). There is a good reason
> why the CRAN build uses gcc3 and g77.
That was a nice clear statement. So given that I want to compile R
from source (because I need the devel version), without too much
hassle I should use gcc 3.3 supplied by Xcode 2.1. But what do I do
with respect to the Fortran compiler?
How close should the versions match? Should I get
- gcc 3.3.6 (latest version of the 3.3 branch) from Gnu's website
- gcc 3.4.4 from Gnu's website
- gcc 3.4 from the hpc.sourceforge website
Is using the 3.4 from the hpc site recommended? Or should I go for a
closer version match and use 3.3.6 from Gnu's website?
Kasper
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
