BUG: included Accelerate.h instead of deprecated vecLib #276

merged 1 commit into from Aug 1, 2012


None yet

5 participants

minrk commented Jul 25, 2012

#include <vecLib/vecLib.h> fails with Xcode 4.4/OS X 10.8

This change lets scipy build on Xcode 4.4/OS X 10.8, System Python 2.7.2

I don't know what the actual implications of this might be, so a more informed developer should probably check this out before it goes in.

should fix #1710: http://projects.scipy.org/scipy/ticket/1710

@minrk minrk BUG: included Accelerate.h instead of deprecated vecLib
#include <vecLib/vecLib.h> fails with Xcode 4.4/OS X 10.8
vene commented Jul 27, 2012

I had to make these exact changes in order to build the stable version 0.10.1. Do you think this warrants a 0.10.2?

Also I get some BLAS test failures: http://pastebin.com/QgHJLRAk. Numpy and scikit-learn tests pass though.

minrk commented Jul 28, 2012

I can't really speak to the release policy, but if uptake of 10.8 is fast, it may be warranted.

On the blas errors, it looks like all of the failures indicate that single-precision is not handled correctly:

from scipy.lib.blas import cblas

print cblas.sasum([1])
# 0.0
print cblas.sasum([1.1])
# -1.0842021724855044e-19
print cblas.sasum([1.2])
# 2.0
print cblas.sasum([1.3])
# -2.0
print cblas.sasum([1.5])
# 0.0

double-precision seems to be handled just fine.

pv commented Jul 29, 2012

AFAIK, some of the single precision functions in Veclib have g77 ABI, some have gfortran ABI, which is a source of this mess. (Above, I suspect scipy.lib.blas.cblas is scipy.lib.blas.fblas). Similar problems occur with complex values, but those we already work around by using the C-BLAS functions instead. Reference: http://projects.scipy.org/scipy/ticket/1618

On releases: I suspect 0.10.2 is unlikely, 0.11.0 more likely.

minrk commented Jul 29, 2012

Thanks for the info (yes, blas.cblas is blas.fblas). So it sounds like the error is unrelated to the transition from vecLib to Accelerate, and should be considered a separate issue from this one. Is that right?


Works fine on OS X 10.6 too. I think it's OK to commit this and backport to 0.11.x too.

@rgommers rgommers merged commit e75a94b into scipy:master Aug 1, 2012
rgommers commented Aug 1, 2012

Mike Wimmer provided on ticket 1710 the link to the docs showing that this change should be fine from OS X 10.3. So merged. Thanks all.

nerduno commented Aug 8, 2012

This didn't fix the problem for me. I was getting the same compilation error related to #include <vecLib/vecLib.h> described by minrk, but having pulled the fix with #include <Accelerate/Accelerate.h>, the same file still fails to compile with a series of errors:

In file included from /System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:43,

                 from /System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:20,

                 from scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c:2:

/System/Library/Frameworks/vecLib.framework/Headers/vfp.h: In function ‘vceilf’:

/System/Library/Frameworks/vecLib.framework/Headers/vfp.h:53: error: incompatible types in return

/System/Library/Frameworks/vecLib.framework/Headers/vfp.h: In function ‘vfloorf’:

/System/Library/Frameworks/vecLib.framework/Headers/vfp.h:54: error: incompatible types in return

Any suggestions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment