[Top][All Lists]

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

[Octave-bug-tracker] [bug #32120] complex times complex failure

From: Michael C. Grant
Subject: [Octave-bug-tracker] [bug #32120] complex times complex failure
Date: Sat, 22 Mar 2014 15:31:00 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9

Follow-up Comment #36, bug #32120 (project octave):

Folks, I would now recommend that this bug be closed all over again.

It turns out that the problems we're seeing are largely caused by an
inconsistent treatment of BLAS across the various libraries that Octave
depends upon: QRUpdate, ARPACK.

For instance, if you simply compile QRUpdate and ARPACK with -ff2c, and Octave
with -ff2c as well, everything works fine. And since ARPACK and QRUpdate
export only subroutines, compiling them with -ff2c does not break any GNU
Fortran code that links with them. They work both sides of the proverbial

Problems arise when using "shims" to fix the BLAS issues on the Mac, such as
"blaswrap.c" here in Octave or "dotwrp" out on GitHub. If Octave is configured
not to use dotwrp, but QRUpdate includes it statically (which is currently the
case on Homebrew), Octave will break in exactly the fashion described here.

Bottom line: this isn't really Octave's fault. It should be documented
heavily, and the package managers may need fixing. I'm working hard on the
Homebrew side of things. Hopefully we'll get this nailed down soon.

I've led you on a couple of wild goose chases here. I apologize. If it is any
consolation, I've created a bunch of brand new code to fix BLAS/LAPACK
incompatibilities that I'm now recommending nobody use.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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