Implement compile-time check for minimum LAPACK version

[rgommers]

In v1.2.0 we increased the minimum required LAPACK version to 3.4.1. That created, for the first time in a very long time, a situation where some distros and macOS ship LAPACK implementations that don't meet our requirements. We now don't check for that situation thoroughly, but may fail at import time (e.g. gh-9657).

We should fix this as far as possible. Not completely trivial to do, since there is no API for this. Probably the best way is to do a compile time check for the presence of some function that was introduced in the minimum LAPACK version we require.

[ilayn]

If there is a possibility to initially compile a single symbol, ilaver returns back the version of LAPACK. But I'm not sure how to trigger this information.

[ev-br]

I guess one can compile and run a simple program in a subprocess?

numpy seems to do something fancier at build time: https://github.com/numpy/numpy/blob/master/numpy/core/setup.py#L667

[tylerjereddy]

Looks like try_link is from vanilla distutils here. Some of the functions in that module do indeed look useful for this kind of thing. I've been thinking of something somewhat similar in numpy/numpy#12523, but this is a useful reminder that there may be some tricks I hadn't considered for "inline compilation" to check basic things like version numbers.

[ev-br]

One other option is of course to implement the version check as a test.

[tylerjereddy]

Bumping the milestone on this one -- I've had some success doing this kind of thing for OpenBLAS in NumPy in numpy/numpy#12790, but experience there suggests we probably won't want to rush this in before cutting the branch

[tylerjereddy]

bumping milestone