Skip to content

Conversation

mattip
Copy link
Collaborator

@mattip mattip commented Jun 28, 2025

  • I updated the package version in pyproject.toml and made sure the first 3 numbers match git describe --tags --abbrev=8 in OpenBLAS at the OPENBLAS_COMMIT. If I did not update OPENBLAS_COMMIT, I incremented the wheel build number (i.e. 0.3.29.0.0 to 0.3.29.0.1)

@mattip
Copy link
Collaborator Author

mattip commented Jun 29, 2025

I can't get this to work. It seems somehow specifying CC messes with the cross-compilation.

@rgommers
Copy link
Collaborator

Can I ask what motivated the attempt to try making this switch? Using Clang seems healthier on macOS, since that's how everything gets compiled and it avoids pulling in C/C++ runtime libs.

@mattip
Copy link
Collaborator Author

mattip commented Jun 30, 2025

There is a floating point error emmited in zgetrf on macos-arm64 that I am trying to track down. It does not appear on the cirrusCI builds, but can be reproduced by rebuilding locally. I am trying to determine what combination of compiler + processor triggers the FPE. Locally, when I build OpenBLAS with GCC I do not see the FPE, so I was trying to replicate that success here.

It seems this is not the correct path, closing.

@mattip mattip closed this Jun 30, 2025
@rgommers
Copy link
Collaborator

I can't see so quickly if zgetrf uses a BLAS function that uses SME, but if so it could be similar to numpy/numpy#29223.

I also noticed that the macos-arm64 builds on this repo still use macos-13 x86-64 runners, which probably doesn't make too much sense anymore and will make it hard or impossible to see this in CI. Switching to macos-latest would be useful either way.

@mattip mattip mentioned this pull request Jul 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants