BUG(?): Symbol not found: _cblas_caxpy$NEWLAPACK #25026
Comments
|
Does |
|
Output of Log is at https://gist.github.com/mdhaber/cad25624c63a15fa9c392716799b4657 I was planning to update macOS to Sonoma. LMK if I should hold off. |
|
The relevant part is this, your build is using a version of Accelerate. @rgommers might know what is going on. |
|
Yes, that's why I was thinking of updating my OS. I saw that 34afbb9 is just tested with macOS 13.3+. I currently have 13.0 after the factory reset. Not sure what I had before, though. |
|
The following works for me: On macOS 14.0 with Xcode 15 and gfortran12 from https://github.com/fxcoudert/gfortran-for-macOS/releases. I wonder if it's a consequence of using the conda compilers? |
@mdhaber yes it'd be great if you could hold off on upgrading to 14.0 to see if we can sort this out. This is the first time a bug against building with Accelerate was reported, and I'd like to get to the bottom of it. The way this is supposed to work is that Accelerate is only detected for macOS >=13.3 and if XCode is new enough so the relevant SDK is installed. This is tested during the build with: so the output of that on your local system is relevant. Conda env/compilers yes/no should not be relevant here. The build log output for this Accelerate detection looks as expected. It's kinda unfortunate that you don't know what OS version you were on before. Can you still reproduce the issue? If so, can you check:
|
|
Yes, I can still reproduce the issue.
|
|
Thanks, that helps. This is kinda the opposite problem of #24053 (comment), which was "OS is 13.3, but SDK is older". What is happening here is that your OS version is 13.0 but you do have an SDK for 13.3, which is picked as the default. Hence, a binary is built that will run on 13.3 - but not on 13.0. I didn't realize that this was a thing, I thought the default would always be the current OS version (and using We're going to need an extra safeguard for this. Just checking: does |
|
Ah, why this "SDK too new" normally isn't really a problem is because the default deployment target indeed is "current OS version" (see https://opensource.apple.com/source/cctools/cctools-667.10.0/libstuff/macosx_deployment_target.c.auto.html) and then using a header will hide the too-new stuff. But in this case we're not actually using the |
|
@mdhaber I think this change will fix it: rgommers/meson@1435e7e. Could you try that? It should have the effect of not selecting Accelerate when you're on <13.3, and once you upgrade to 13.3 or later it will pick it up (and then it'll work). |
|
Updated commit linked above to also include |
|
|
|
While we're at it, Testing Builds says to |
Yes, I planned to rewrite basically all the docs, and mostly copying the structure SciPy has because that is much clearer and more comprehensive. |
Incorporates numpy/meson#6 Closes numpygh-25026 [skip azp] [skip circle]
|
Figured out there's no need to call |
Describe the issue:
On my M1 mac, I can build commit d10d17e and import NumPy without issue. With the next commit, 34afbb9, the build seems to be successful, but I get an error when I try to
import numpyat the Python prompt.I get the full error message below when I use an editible install and try to import NumPy. When I use
spin test -v, the build seems OK, but it fails with the sameImportError.In case it matters, I use Miniforge mamba to set up the
numpy-devenvironment. This is on a fresh system; I did a factory reset in my attempt to debug this. I've read through https://numpy.org/devdocs/user/troubleshooting-importerror.html as recommended and couldn't find a solution there.Update: I'm upgrading from Ventura to Sonoma to see if that helps.
Reproduce the code example:
Error message:
Runtime information:
The text was updated successfully, but these errors were encountered: