Thanks Nathan!

I might make it harder to install lapack-lite in the free-threaded build as a followup.

xref #26157 (comment) where we discussed this. I'm fine with this deviation if it's still necessary after this PR. But if the locking fixes it, I'd prefer not to do this, since it will cause other problems when building numpy from source in downstream CI.

This doesn't look right, unfortunately. I don't know why we even have this lapack_lite module, it belongs deprecated (probably because it was a "private" version used before the linalg-umath existed).
Adding locking here fixes an issue in the free-threaded build for the lapack_lite module and I am happy if you just want to merge it, but that is pretty unimportant and doesn't close the issue.

The locks need to be either:

• in the lapack_lite functions that get called here (and more), or
• in umath_linalg.cpp and only if the lapack backend isn't threadsafe which is probably just lapack-lite.

My guess is that the second one is simpler.

IIRC I looked at completely removing lapack_lite recently, but it was complicated because of some direct usage in testing - so I left it alone. So I'd merge this as is. You're right though @seberg that adding locks in umath_linalg is also needed (and more important).

My guess is that the second one is simpler.

I think so too.

I think we can just delete (or deprecate) it, the only test that looks important is for xerbla and that:

• Is skipped when it fails, so we don't know when it fails anyway.
• We should try to never pass invalid parameters to lapack. See for example BUG: Silent int32 overflow in lapack work size computation leads to wrong exception #25564 for an example where this happens and that xerbla does not kick in.

Now, it would be nice to use our xerbla and give a good error for example in that issue! But it looks like it either doesn't work on all systems (e.g. due to mac dynamic linking resolution working differently) or probably never worked (or at least in a long time) for anything but lapack-lite, at least not in years...

Thanks for the pointer, this is my first time touching the linalg module so the structure wasn't clear initially. I think I'll close this and do this in two followups. First, right now there isn't a way to tell from inside the source code what BLAS is being used, so I need to add some meson logic to generate a macro that is set when lapacklite is being used.

Next, I can add a new global static lock in the umath_linalg module and then acquire and release it in that module. I might end up putting the locking in the functions exposed to Python rather than around every BLAS call for the sake of simplicity.