[Scipy-tickets] [SciPy] #1737: OS X Mountain Lion test failures

SciPy Trac scipy-tickets@scipy....
Sun Oct 7 11:45:09 CDT 2012


#1737: OS X Mountain Lion test failures
--------------------------+-------------------------------------------------
 Reporter:  aleach        |       Owner:  cdavid      
     Type:  defect        |      Status:  needs_review
 Priority:  normal        |   Milestone:  Unscheduled 
Component:  Build issues  |     Version:  0.10.0      
 Keywords:  OSX, ATLAS    |  
--------------------------+-------------------------------------------------

Comment(by aleach):

 I've tested that sample SDOT test from [http://www.macresearch.org
 /lapackblas-fortran-106#comment-17216 Jarno] on my machine, using
 Accelerate blas and various flag combinations. Good sample!

 ''' Accelerate from 10.8 SDK '''

 ''32 bit, -ff2c''
 {{{
 $ gfortran testblassdot.f -ffree-form -ff2c -m32 -o testblasdot -L/usr/lib
 -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       2.000000
  (  1.000000    ,  1.000000    ) (  1.000000    ,  2.000000    ) (
 -1.000000    ,  3.000000    ) ( -1.000000    ,  3.000000    )
 }}}

 ''64-bit, -ff2c''
 {{{
 $ gfortran testblassdot.f -ffree-form -ff2c -m64 -o testblasdot -L/usr/lib
 -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       2.000000
  (  1.000000    ,  1.000000    ) (  1.000000    ,  2.000000    ) (
 -1.000000    ,  3.000000    ) ( -1.000000    ,  3.000000    )
 $ otool -L ./testblasdot
 testblasdot:
 /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
 (compatibility version 1.0.0, current version 1.0.0)
         /usr/local/lib/libgfortran.2.dylib (compatibility version 3.0.0,
 current version 3.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 169.3.0)
 }}}

 ''32-bit''
 {{{
 $ gfortran testblassdot.f -ffree-form -m32 -o testblasdot -L/usr/lib
 -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       2.000000
 Bus error: 10
 }}}

 ''64-bit''
 {{{
 $ gfortran testblassdot.f -ffree-form -m64 -o testblasdot -L/usr/lib
 -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       0.000000
 Segmentation fault: 11
 }}}

 ''' Accelerate from 10.7 SDK '''

 '32 bit, -ff2c''
 {{{
 $ gfortran testblassdot.f -ff2c -ffree-form -m32 -o testblasdot
 -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib
 -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       2.000000
  (  1.000000    ,  1.000000    ) (  1.000000    ,  2.000000    ) (
 -1.000000    ,  3.000000    ) ( -1.000000    ,  3.000000    )
 }}}

 ''64-bit, -ff2c''
 {{{
 $ gfortran testblassdot.f -ff2c -ffree-form -m64 -o testblasdot
 -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib
 -lblas -L/usr/local/lib
 $ ./testblasdot
    1.000000       2.000000       2.000000       2.000000
  (  1.000000    ,  1.000000    ) (  1.000000    ,  2.000000    ) (
 -1.000000    ,  3.000000    ) ( -1.000000    ,  3.000000    )
 $ otool -L ./testblasdot
 ./testblasdot:
 /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
 (compatibility version 1.0.0, current version 1.0.0)
         /usr/local/lib/libgfortran.2.dylib (compatibility version 3.0.0,
 current version 3.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 159.1.0)
 }}}

 Oh, it looks like I can't actually link to the 10.7 libBLAS because it's
 install_name points straight to the libBLAS I have as part of the 10.8 OS.
 I tried pointing the '-isysroot' to the SDK root dir, but the dynamic
 linker still picks up the system libBLAS because of the install_name.
 Running testblasdot with DYLD_LIBRARY_PATH set will probably pick up the
 10.7 blas though, although I'm not entirely sure of that, as running otool
 -L with DYLD_LIBRARY_PATH set, still points to the system libBLAS.. Either
 way, the tests appear to give identical results to the 10.8 libBLAS, for
 -fno-f2c as well.



 '''libblas.dylib built from Netlib Lapack 3.4.2'''

 ''64-bit, -ff2c''
 {{{
 $ gfortran testblassdot.f -ffree-form -ff2c -m64 -o testblasdot -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       0.000000
 Segmentation fault: 11
 $ otool -L ./testblasdot
 testblasdot:
         libblas.dylib (compatibility version 0.0.0, current version 0.0.0)
         /usr/local/lib/libgfortran.2.dylib (compatibility version 3.0.0,
 current version 3.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 169.3.0)
 }}}

 ''64-bit, -fno-f2c''
 {{{
 $ gfortran testblassdot.f -ffree-form -m64 -o testblasdot -lblas
 $ ./testblasdot
    1.000000       2.000000       2.000000       2.000000
  (  1.000000    ,  1.000000    ) (  1.000000    ,  2.000000    ) (
 -1.000000    ,  3.000000    ) ( -1.000000    ,  3.000000    )
 }}}

 When I don't explicitly use '-L/usr/lib', gfortran links against the
 libblas.dylib I built as part of Netlib Lapack, and installed into
 /usr/local/lib. LD_LIBRARY_PATH is unset btw, but the dynamic linker seems
 to pick up libraries in /usr/local/lib in preference to /usr/lib. My
 lapack wasn't built with the -ff2c flag btw, which would explain the above
 results, and some of the problems I've been getting when using my ATLAS
 build.. Thanks for pointing me in the right direction with that!

 The Accelerate framework looks solid here with -m64, and -ff2c appears to
 be a requirement.

 So, I think I'll rebuild lapack and blas with -ff2c now...
 Before I do, I've one thing I wanted to ask about the ff2c flag. Pretty
 much all I know about it is in the gfortran man page, which has this to
 say:-

 {{{
 -ff2c
     Generate code designed to be compatible with code generated by g77 and
 f2c.

     The calling conventions used by g77 (originally implemented in f2c)
 require
     functions that return type default "REAL" to actually return the C
 type
     "double", and functions that return type "COMPLEX" to return the
 values via an
     extra argument in the calling sequence that points to where to store
 the return
     value.  Under the default GNU calling conventions, such functions
 simply return
     their results as they would in GNU C---default "REAL" functions return
 the C
     type "float", and "COMPLEX" functions return the GNU C type "complex".
     Additionally, this option implies the -fsecond-underscore option,
 unless
     -fno-second-underscore is explicitly requested.

     This does not affect the generation of code that interfaces with the
     libgfortran library.

     Caution: It is not a good idea to mix Fortran code compiled with -ff2c
 with
     code compiled with the default -fno-f2c calling conventions as,
 calling
     "COMPLEX" or default "REAL" functions between program parts which were
 compiled
     with different calling conventions will break at execution time.

     Caution: This will break code which passes intrinsic functions of type
 default
     "REAL" or "COMPLEX" as actual arguments, as the library
 implementations use the
     -fno-f2c calling conventions.
 }}}


 That last caution makes me wonder about what happens when BLAS uses
 intrinsic math functions, like sum or sqrt, which can take and return REAL
 or COMPLEX datatypes. I can't tell from the above if there's any
 truncation or data loss when REAL and COMPLEX types are converted to the C
 representations. Do you know if there is? I guess I could find out by
 printing sqrt(2) or something, using the various flags.. Ahh, just seen
 with {{{ nm /usr/local/lib/libgfortran.dylib }}} that each of the
 intrinsic math functions have alternative versions; e.g.
 _f2c_specific__sqrt_r4 and _specific__sqrt_r4. Might have to explicitly
 test some of these out if I get errors with BLAS when using ff2c..

-- 
Ticket URL: <http://projects.scipy.org/scipy/ticket/1737#comment:12>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.


More information about the Scipy-tickets mailing list