[MacPorts] #35508: arpack port does not work on Lion with GFortran 4.6.2 due to Accelerate problem

[MacPorts]

#35508: arpack port does not work on Lion with GFortran 4.6.2 due to Accelerate
problem
-----------------------------------+----------------------------------------
 Reporter:  gcrosswhite@…          |       Owner:  mmoll@…           
     Type:  defect                 |      Status:  new               
 Priority:  Normal                 |   Milestone:                    
Component:  ports                  |     Version:  2.1.2             
 Keywords:                         |        Port:  arpack            
-----------------------------------+----------------------------------------

Comment(by gcrosswhite@…):

 I didn't see anything in /opt/local/var/macports/logs, but I wasn't
 expecting to as the port builds just fine; the problem is that the
 resulting library is not okay because it segfaults at runtime because it
 is using the wrong calling convention for some BLAS routines such as
 zdotc.

 To create a simple test case that illustrates the problem, I compiled the
 test program zndrv1.f in EXAMPLES/COMPLEX of the main ARPACK distribution
 and linked it against the MacPorts build of libarpack.a.  The result was:

 {{{
 $ gfortran zndrv1.f /opt/local/lib/libarpack.a -framework Accelerate
 $ ./a.out
 zsh: segmentation fault  ./a.out
 }}}

 We can see where the segmentation fault is coming from by using gdb:

 ----
 {{{
 $ gdb ./a.out

 GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC
 2012)
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for
 details.
 This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
 shared libraries ..

 (gdb) run

 Starting program: /Users/gcross/Downloads/ARPACK/EXAMPLES/COMPLEX/a.out
 Reading symbols for shared libraries +++++................................
 done

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000015
 0x00007fff87f02d9a in zdotc_ ()

 (gdb) backtrace

 #0  0x00007fff87f02d9a in zdotc_ ()
 #1  0x0000000100009f8f in zneupd_ ()
 #2  0x0000000100002ac1 in MAIN__ ()
 #3  0x0000000100003833 in main ()
 }}}
 ----


 So in conclusion the crash is related to zdotc, and when I linked the test
 program against my own version of libarpack.a which did the replacement I
 discussed earlier the program ran just fine:

 {{{
 $ gfortran zndrv1.f /usr/local/lib/libarpack.a -framework Accelerate
 $ ./a.out

  Ritz values (Real, Imag) and relative residuals
  -----------------------------------------------
                Col   1       Col   2       Col   3
   Row   1:    7.16197D+02   1.02958D+03   6.80426D-15
   Row   2:    7.16197D+02  -1.02958D+03   9.03466D-15
   Row   3:    6.87583D+02   1.02958D+03   1.11184D-14
   Row   4:    6.87583D+02  -1.02958D+03   1.58575D-14


  _NDRV1
  ======

   Size of the matrix is          100
   The number of Ritz values requested is            4
   The number of Arnoldi vectors generated (NCV) is           20
   What portion of the spectrum: LM
   The number of converged Ritz values is            4
   The number of Implicit Arnoldi update iterations taken is           25
   The number of OP*x is          392
   The convergence criterion is   1.11022302462515654E-016
  }}}

 So, this doesn't quite answer your question, but it is the closest answer
 I can think of at the moment that provides you with a log that records the
 problem, as well as an example easily available test case that triggers
 it.

-- 
Ticket URL: <https://trac.macports.org/ticket/35508#comment:4>
MacPorts <http://www.macports.org/>
Ports system for Mac OS