octave-3.2.2 needs FFLAGs='-ff2c' to use system BLAS (-framework Accelerate) with gcc43/gcc44

[todmorrison (Tod Morrison)]

Without the FFLAG '-ff2c' with gcc43 and gcc44 a check for whether certain BLAS routines are called correctly during configure will fail and as a result the build will use the reference BLAS rather than the optimized BLAS available in the Accelerate framework. Adding,

  configure.fflags='-ff2c'

corrects this problem and allows Octave to compile against the optimized library.

[luis.beca@…]

Cc Me!

[alakazam@…]

I have just added

configure.fflags    -ff2c

to the Portfile. The configure phase seems to show that this option is used, but doesn't fix the issue :

(...)
configure: defining FFLAGS to be -ff2c -m64 -mieee-fp
(...)
configure: WARNING: A BLAS library was detected but found incompatible with your Fortran 77 compiler.  The reference BLAS implementation will be used. To improve performance, consider using a different Fortran
 compiler or a switch like -ff2c to make your Fortran compiler use a calling convention compatible with the way your BLAS library was compiled, or use a different BLAS library.
(...)

[alakazam@…]

Switching to having atlas as a dependency fixes this issue.

[alakazam@…]

Fixed in r61160.

[todmorrison (Tod Morrison)]

Deleting the dependency on Atlas and adding configure.fflags="-ff2c" works for me and enables proper linking with vecLib. Linking to atlas is an inferior option, since one of the advantages of OSX is it's vendor optimized Blas/Lapack libraries.

[tenomoto (Takeshi Enomoto)]

Sorry to write to a closed ticket. I prefer Accelerate.framework because of 1) performance and 2) lack of +g95 in atlas. However, gfortran fails with sdot with -ff2c and with cdotu and zdotu without -ff2c. With trial and error I found that octave is configured to use Accelerate.framework with -fdefault-real-8 and explicit specification of type (real*4 for sdot and complex*8 for cdotu). I would think this problem pertains to x86_64 and ppc64 only but I have not tested. G95 does not have this problem. I will attach a patch.

[tenomoto (Takeshi Enomoto)]

Forgot to mention that arpack requires Accelerate. That is why -framework Accelerated is added to LIBS.

[tenomoto (Takeshi Enomoto)]

Cc Me!

[jjstickel@…]

Cc Me!

[jjstickel@…]

Cc Me!

[todmorrison (Tod Morrison)]

I believe the portfile patch to add a no_atlas variant in Ticket #22997 resolves this problem as well.

[todmorrison (Tod Morrison)]

Cc Me!

[todmorrison (Tod Morrison)]

Cc Me!

[tenomoto (Takeshi Enomoto)]

I updated the patch and addressed the *dot* problem (​solution).

In order to build atlas free octave:

1. Install SuiteSparse with +accelerate (or simply +g95 if you prefer g95 to gfortran).
2. Use the patch #25186 and install arpack with +accelerate (or simply +g95 if you prefer g95 to gfortran).
3. Use the patch here to install octave ith +accelerate (or simply +g95 if you prefer g95 to gfortran). With g95 put dotwrp.f90 into files.

[tenomoto (Takeshi Enomoto)]

Oops +accelerate of qrupdate has been renamed. use +no_atlas.

[tenomoto (Takeshi Enomoto)]

Corrections to the procedure to build atlas free octave and formatting.

• SuiteSparse does not have accelerate or g95 options. I confused it with arpack.

1. Use the patch #25186 and install arpack with +no_atlas (or simply +g95 if you prefer g95 to gfortran).
2. Use the patch here to install octave with +no_atlas (or simply +g95 if you prefer g95 to gfortran). With g95 put dotwrp.f90 into files.

[michaelld (Michael Dickens)]

Cc Me!

[tenomoto (Takeshi Enomoto)]

I updated the patch. The previous one builds fine but mkoctfile had a bad reference to dotwrp.o in a temporary file and did not function. I made dotwrp a separate port. I am testing the same with octave-devel but I have a problem with liboctinterp.dylib. It has a reference to a function which does not exist in none of libstdc++ installed on my machine. With the stable octave-3.2.4 the patch works fine for me.

[tenomoto (Takeshi Enomoto)]

a patch to enable link agains Accelerate.framework (rev 3 added --with-blas="-framework Accelerate")

[jmroot (Joshua Root)]

Committed a variation on this patch in r74740. Unfortunately there is a bug with 64-bit SDOT in 10.6's Accelerate.framework, so the new variant can't be used there.

[tenomoto (Takeshi Enomoto)]

Great news! Thank you for the update.

I look at the MacResearch ​webpage. I was able to run that test successfully without -ff2c and with ​dotwrp.

$ gfortran-mp-4.5 -fno-underscoring dotwrp.f90 -c
$ ar cru libdotwrp.a dotwrp.o
$ gfortran-mp-4.5 my_conftest.f -L. -ldotwrp -framework Accelerate
$ ./a.out   1.0000000       2.0000000       2.0000000       2.0000000    
 (  1.0000000    ,  1.0000000    ) (  1.0000000    ,  2.0000000    ) ( -1.0000000    ,  3.0000000    ) ( -1.0000000    ,  3.0000000    )

I added gcc44 and gcc45 variants to dotwrp (r74749). The same approach as g95 might work as well for gcc44 and gcc45.