@mattip @h-vetinari Ping. Note that the openblas libraries are still labeled 10.9.

There are Fortran problems. I assume something like

LIBRARY_PATH: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib

is needed here. @mattip ?

It seems something like that might be needed for the gfortran compiler.

See https://github.com/scipy/scipy/blob/1d80a2f254380d2b45733258ca42eb6b55c8755b/.github/workflows/wheels.yml#L82-L87 for more details on gfortran. Cc @andyfaff, who discovered the same issue when updating SciPy wheel builds.

Thanks Ralf. Makes me curious as to why macos-11 works on azure. In any case, I think we should put some effort into getting this working. Do you think macos-12 would be a better target? That seems to be what SciPy is using for the arm64 builds.

Do you think macos-12 would be a better target? That seems to be what SciPy is using for the arm64 builds.

macOS 11 has a bug that leads to a kernel panic when used with some functionality in sparse.linalg, that's why we're avoiding shipping wheels for macOS 11. For NumPy it's better to stay on 11.

Over at #22525 I am trying to get OpenBLAS 0.3.21 working. In PR MacPython/openblas-libs#89 I built the openblas libraries and updated the macOS image to mac-11 without updating the gfortran toolchain on macOS.

Here are my notes from fiddling around today when trying to build macosx_x86_64 wheels on my scipy fork:

1. I changed the macOS image from macos-10.15 to macos-11. I also changed OpenBLAS to v0.3.21.
2. When I do that the gfortran-4.9.0-Mavericks compiler can no longer be used to compile programs - it just doesn't work on macos-11.
3. I then installed gfortran-11.2 for BigSur from fxcoudert instead of the ancient version of gfortran.
4. When I use this compiler I get lots of

  ld: warning: dylib (/usr/local/gfortran/lib/libgfortran.dylib) was built for newer macOS version (11.5) than being linked (10.9)
  ld: warning: dylib (/usr/local/gfortran/lib/libquadmath.dylib) was built for newer macOS version (11.5) than being linked (10.9)

5. If I try to set MACOSX_DEPLOYMENT_TARGET=10.15 I (obviously) still get the warnings. I therefore tried older compilers to see if I could go further back than 11.5.
6. I then tried using gfortran-8.2 and set MACOSX_DEPLOYMENT_TARGET=10.15. This time when I build I no longer get the ld warnings from step 5.
7. The build 'completes'. However, the delocate step fails:

/usr/local/gfortran/lib/libgfortran.3.dylib not found:
    Needed by: /usr/local/lib/libopenblas.0.dylib
ERROR:delocate.libsana:
  /usr/local/gfortran/lib/libgfortran.3.dylib not found:
    Needed by: /usr/local/lib/libopenblas.0.dylib

This is because OpenBLAS on anaconda is built against libgfortran.3.dylib, but gfortran-8 supplies libgfortran.5.dylib.
8. In order to get libgfortran.3.dylib you have to use gfortran <= 6.x. I didn't try gfortran-6.3 because it's quite old.

From discussions elsewhere it seems that there's a desire (at least in scipy) to update to at least gfortran-8. From my understanding of the above behaviour this would at least allow one to target 10.15. A deployment target of 10.9 doesn't seem sensible to me.

Perhaps we need to:

1. Make gfortran-8 the minimum compiler (libgfortran.5.dylib)
2. Update the deployment target to 10.15 across the board.
3. Update the OpenBLAS multibuild on macos to reflect 1+2.
4. On scipy can we bump to OpenBLAS v0.3.21?

Note: this only applies to the x86_64 builds, the arm64 gfortran compilers are much more modern.

@mattip, what gfortran compiler did you get to work on macos-11, that uses libgfortran.3.dylib (needed by the OpenBLAS on anaconda), that can also deploy against 10.9/10.14/10.15?

what gfortran compiler did you get to work

In #22525 I did not update the macos image at all.

Perhaps we need to: ...

These steps make sense to me. Would you like to submit a PR to MacPython/openblas-libs?

+1 to bumping to at least gfortran 8.

Regarding minimum macOS version: 10.15 is a bit too aggressive; the problem is that users on <=10.14 will then get builds from source, rather than an older wheel. 10.14 is about 4 years old, and I expect it's still around enough to be a problem in practice. I also had a quick browse around, currently Matplotlib uses 10.12 and PyArrow 10.14, those are the newest versions I found. I'd expect that 10.12 or 10.13 would be okay, 10.14 borderline, and 10.15 too new.

These steps make sense to me. Would you like to submit a PR to MacPython/openblas-libs?

Normally yes, but it's not quite clear to me where to even start.

Ok, let me try.

I then tried using gfortran-8.2 ...

I think this should replace the one in https://github.com/MacPython/gfortran-install/tree/master/archives, and the README updated appropriately

xref MacPython/openblas-libs#90

Will gfortran 8.2 for Mojave (macOS 10.14) actually install on macos 11?

There are now macos-10.11 builds of openblas 0.3.21 with the gfortran8 gfortran compiler on https://anaconda.org/multibuild-wheels-staging/openblas-libs/files. If we could easily update to 0.3.21, we could change the openblas suffix to 10_11 instead of 10_9. Unfortunately then using 0.3.21 will hit the windows build problems from #22525.

That compiler was built for macos 10.14, and there are ld warnings

ld: warning: dylib (/usr/local/gfortran/lib/libgfortran.dylib) was built for newer macOS version (10.14) than being linked (10.11)

Will that cause problems when targeting 10.11?

@mattip Why 10.11?

Why 10.11

If we are not going with 10.14, then 10.11 seemed like a good minimum version.

I think it would be a good time to retry the "repackage-gfortran-from-conda-forge" idea. Our gfortran is compatible all the way back to 10.9.

At the time it wasn't clear where to do the repackaging: MacPython/gfortran-install#7

CC @isuruf

Will gfortran 8.2 for Mojave (macOS 10.14) actually install on macos 11?

The installer package I linked to above is installable on the GH Actions macos-11 image (already tried that).

That compiler was built for macos 10.14, and there are ld warnings
ld: warning: dylib (/usr/local/gfortran/lib/libgfortran.dylib) was built for newer macOS version (10.14) than being linked (10.11)
Will that cause problems when targeting 10.11?

From what the warning says I would've thought so, perhaps the minimum macOS version we can target with that compiler becomes 10.14. I tried to search for the warning but get no clear guidance on whether binaries built with that would work on <10.14.

There may be compilers for gfortran-8 that were built for older macOS, but I can't find any immediately. This page has a gfortran-6 package for 10.11 and up.

I can repackage one from conda-forge for you until we figure out MacPython/gfortran-install#7

Which gfortran do you need? 9.5.0 or 10.4.0 or 11.3.0? They'll be compatible with macos 10.9 and later

Which gfortran do you need?

I can't speak for the exact gfortran version we need from a scipy POV (@rgommers will know) but the gfortran needs:

• be usable/installable on macos-11 (e.g. GH Actions image)
• compatibility with 10.9 is great.
• for native x86_64 compilation

scipy then needs an OpenBLAS build with the above (either v0.3.18 or v0.3.21).

(Sorry if the above is stating the obvious).

@andyfaff, see MacPython/gfortran-install#11

I note that gfortran-8.2-Mojave.dmg has the wrong file name inside, we want gfortran, it has gfortran-8.2-Mojave. The original 4.9 version we were using was modified so that the internal file was gfortran. With that change, I suspect we could solve some of our problems.

I note that gfortran-8.2-Mojave.dmg has the wrong file name inside

The file inside the DMG has a funny name, but is macOS installer PKG. Once the installer has run it places a gfortran executable in the right place with the right name.

but is macOS installer PKG

It doesn't have the .pkg extension, does that matter?

Sorry, the installer is within that folder, /Volumes/gfortran-8.2-Mojave/gfortran-8.2-Mojave/gfortran.pkg

I'm going to look into the solution posted by @isuruf this morning for scipy.

I'm going to look into the solution posted by @isuruf this morning for scipy.

The wheels build now, but fail during delocate because of OpenBLAS. @mattip What needs to be done to use the new OpenBLAS builds? Are they against gfortran 8.2?

EDIT: In particular, do they use libgfortran.5.dylib

There are a few intertwined factors here. We need to update to a newer version of gfortran because gfortran-4.9 doesn't work on macos-11. Whilst the gfortran-8.2 link gets through the compile stage ultimately this solution is not for us because:

1. gfortran-8.2 uses libgfortran.5.dylib and the currently available OpenBLAS on anaconda needs libgfortran.3.dylib. This is causing the delocate step to fail.
2. That gfortran-8.2 is designed to deploy on 10.14 and above. So even if OpenBLAS is rebuilt using that gfortran-8.2 we couldn't target macos-10.13 and below.

The good solution is probably to:

1. Install the gfortran-11.3 compiler suggested by @isuruf in https://github.com/MacPython/gfortran-install/pull/11/files. The compiler can deploy against 10.9.
2. Rebuild the OpenBLAS binaries using this gfortran-11.3.

@charris, you can fix that by changing https://github.com/numpy/numpy/blob/main/tools/openblas_support.py#L80 to
suffix = 'macosx_10_11_x86_64-gf_dd3e148.tar.gz'

Mac is working. This is all testing what needs changing right now. All we need is to

• pick a compiler
• compile OpenBLAS with it. Must work with windows
• fix this up to use the new stuff.

Closing in favor of #22525.