#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