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

