Looks like dgelsd is the problem. I'd really like to see windows testing, appveyor is a real bottleneck for us.

+10 for Azure Pipelines. Discussed it with quite a few people, and Steve Dower gave an overview of features, MS's motivations, and what's coming next. Everyone was very positive and enthusiastic about it.

I'd really like to see windows testing

I added Windows / Python 3.6 full tests to matrix; 1 error and a few failures; worse if I try more than 1 core for testing; tempfile stuff and a few other things. I'll try to sort them out.

init_dgelsd failed init issue on the macOS builds is similar to a recent bug report for clang builds with homebrew and recent NumPy, which seems to be circumvented by using a recent version of gcc

I've been able to reduce test skips on the azure mac os image now:
26 failed, 5552 passed, 25 skipped, 12 xfailed, 1 xpassed

But the failures look real and are also reported for macos 10.13 recently for macports.

One user tracked down the source line in Numpy -- I'll see if I can debug that if nobody beats me to it; there's a comment mentioning Fix a bug in lapack 3.0.0 just above the low-level error block -- I bet it is because of something there -- we custom modify something that is fed to malloc because of an alleged lapack bug, but maybe that bug is no longer in play with some recent mac os images / LAPACK library settings, etc.

What version of Lapack is being tested there?

That comment was introduced by me in 92f1d12. I think there are all sorts of bugs in the lapack workspace calculations, which is what motivated my upgrade of lapack_lite a while back.

I think the situation now is that OSX ships with a more broken lapack than the one bundled with numpy.

Can we make the Mac build with the NumPy fallback code? I know we can on Linux, but have never tried on Mac.

I'll have to check re: lapack version -- the show_config style commands don't always make this stuff obvious to me. What is meant by "fallback code?"

Are there any low-level hooks that can be used in C source files to probe LAPACK version during pre-processing / guard the logic for handling the bugs?

I see online that ilaver() function will return lapack version, but it is apparently never used in our source. Looks like scipy exposes it in scipy.linalg.lapack.ilaver

IIRC, on the Mac use of accelerate/veclib is hardwired in, see numpy/distutils/system_info.py. On other platforms one can do

BLAS=None LAPACK=None python setup.py build

which disables linking to the external libraries and uses unoptimized numpy code instead.

Can we close this?

Yeah, the broader setup effort has been completed; some more challenging refinements may remain for i.e., MacOS f2py and test thread safety, etc.