octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wrapper dylib to fix OSX libBLAS & libLAPACK with -m64 (Re: 3.5.0+ c


From: Jarno Rajahalme
Subject: Re: Wrapper dylib to fix OSX libBLAS & libLAPACK with -m64 (Re: 3.5.0+ compiled on Mac OSX 10.6.6)
Date: Fri, 28 Jan 2011 19:21:55 +0200


On Jan 27, 2011, at 13:01 , ext Jarno Rajahalme wrote:


On Jan 26, 2011, at 7:50 , ext Jarno Rajahalme wrote:

IMO it should be noted that, looking at your config.log summary, your build was a 32-bit one. Newer machines (that boot with 64-bit kernel) default to 64-bit builds, which will fail due to Apple veclib bug. To fix that ATLAS needs to be installed, and used as the BLAS library instead of veclib.

Jarno

I made a wrapper (libBLASWRAP.dylib) allowing the use of Apple provided BLAS and LAPACK with 64-bit builds. With this Octave builds and tests fine without additional atlas or lapack. No compilation changes are needed, but -lBLASWRAP needs to be specified for the linker, before Apple's own libraries, or preferably instead of them to avoid any confusion.

The wrapper (blaswrap.c) is included (attachment), comments include instructions for building (using Apple-provided gcc and ld).
<blaswrap.c>


I was a bit too quick. Functions with more than 6 arguments pass the extra args in stack, so the stub has to be a little bit different for them.

I have included a new version fixing this.

Attachment: blaswrap.c
Description: Binary data


Running the LAPACK test suite programs reveals that there are some internal problems with libLAPACK.dylib, that cause crashes. I have also seen independent reports for these crashes elsewhere, so they are not caused by the wrapper. I managed to avoid all crashes by including 6 LAPACK routines (through which the crashes happened) into the wrapper library. The whole library with a Makefile is also attached.

Attachment: blaswrap.tgz
Description: Binary data


I ran all the BLAS and LAPACK tests and only non-100% success cases were on some LAPACK Eigenvalue tests, however, many of these fail in same fashion with lapack 3.1.1 itself. Using a newer BLAS from atlas resolved some (but not all) of the failures. This tells that there are some bugs in the blas routines Apple is using, that have been since fixed in ATLAS.

So, the underlying Apple libraries set some limits on how fat a wrapper like this suffices.

  Jarno


reply via email to

[Prev in Thread] Current Thread [Next in Thread]