Conversation
|
While updating the m4ri package for MSYS2 (Windows) to version 20251206, I found that the code changes from this pull request cause problems when building on ARM64: msys2/MINGW-packages#26746 (comment) Reverting the changes from this pull request makes the build pass again on ARM64. That's what I did for the moment to make the build pass, but that's not ideal. Just for completeness: The code changes seems to work in other MSYS2 environments running on Intel/AMD x86_64 CPUs. |
|
Oh, that's unfortunate. What was the output on ARM64 with the previous output. Did it actually detect L1/L2/L3? |
|
No, it doesn't look like it did. The build log of the previous version can be seen here: https://github.com/msys2/MINGW-packages/actions/runs/19638373164/job/56234870269#step:9:460 Relevant part is this: Cache sizes were detected as zero bytes for all three cache levels on ARM64, so the detection wasn't that helpful there. |
|
Okay, we now write undefined instead of zero so our fallback logic cannot trigger. Could you attach the configure script so I see where the configure script trips over? |
|
Can you try #39 ? |
Didn't test #39 directly but only the new release 20251207 which contains the PR. It works now on ARM64, too. Detected cache sizes are still zero for ARM64 (see https://github.com/msys2/MINGW-packages/actions/runs/20011273268/job/57381132924?pr=26766#step:9:380 for the build log), but there are no more build failures. 👍 |
|
Thanks for checking. That makes sense, someone with Windows + ARM experience will need to contribute code for detecting L1, L2, L3 or equivalent there. |
See #35