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

Merged
merged 1 commit into from Aug 1, 2012

Projects

None yet

5 participants

@minrk
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
8822a75
@vene
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
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
Member
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
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?

@rgommers
Member

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
Member
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
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