Bernard
Here are some possible explanations:
(1) That's impossible.
(2) You sent this on April 1, and the message got delayed.
(3) Some sort of weird compiler problem. Can you re-build from scratch without optimisation? Can you look at the screen when LAPACK/BLAS are compiled to ensure that these are also built without optimisation?
(4) A linker problem, and the code actually uses a different (not the Cactus built-in version) of LAPACK/BLAS. Can you rebuild with SILENT=no as make option, and look at the final link line to see which LAPACK and BLAS versions are used?
(5) In case you use shared libraries: Can you use "ldd" or "otool -L" on the final executable and look which version of LAPCK/BLAS are used?
(6) If you have LAPACK/BLAS installed in a system directory, then Cactus may pick up one of these instead of the built-in one. It is difficult to say which are used; you would need to pass a flag to the linker to make it output that information. Can you try adding "-Wl,-v" (or the equivalent of -v) to LDFLAGS, and then look at the screen output while linking, where the actual LAPACK/BLAS file names that are used should be printed?
(7) The Fortran 77 ABI is very standard. Even mixing different versions won't lead to such a problem. This can't happen.
-erik
On Fri, May 27, 2011 at 12:09 PM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:
Hi all. I recently needed to use a LAPACK routine in a Cactus thorn. Since my local machine's installation of LAPACK & BLAS was old, I decided to force an installation by including the thorns "ExternalLibraries/[BLAS,LAPACK]". This seemed to work, with the resulting .a files ending up in configs/<my config name>/scratch/external/LAPACK, etc. Compiling and running my cactus executable, however, I found the LAPACK gave completely wrong results. For a much simpler test case that (see attached F90 standalone program), consider the 2x2 system A x = b, where A = (3, 2\2, 6), and b = (5, 8). Correct result for "x" is (1,1). Cactus-forced LAPACK (using routine "dgesv") yields (-2,1). I later installed LAPACK (v. 3.3.0) + BLAS by hand on my machine. Linking against these yields the correct answer. I'm on a 32-bit Linux machine, using the Intel 10 compilers. I'd appreciate any insights on this. Thanks, Bernard _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users