Unmaintained GCC/gfortran version is shipped

On macOS, this repo currently ships gfortran and its libraries based on a modified version 11.3.0 https://github.com/isuruf/gcc/releases/tag/gcc-11.3.0-2

GCC 11 has reached EOL 6 months ago, so it seems like a good plan to upgrade to a newer version. I would be willing to help, if someone can clarify what the expectations are (I am a Homebrew and GCC maintainer).

We are working towards eliminating the use of the modified gfortran. So far we have refactored to use the native gfortran supplied with the github runner images, see #211. Unfortunately the move to the macos-15 image seems to have broken the build, see #219 and #223 to try to fix it. If you have any ideas why the build there is failing, we are all ears.

Is there a way to tell macOS to use a different compiler? I am not sure what we were using on the macos-13 builds before #211 ...

“the native gfortran supplied with the github runner images” is gfortran/GCC provided by Homebrew. Several versions are available, see for example https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md

I'm not sure that's suitable for your needs, but I may be misunderstanding the goal of this repo. Homebrew ships software built on every macOS major version, targeting this same macOS version. These versions are not suitable to deploy to earlier macOS versions. For example, on my laptop runnning macOS 26:

$ otool -l /opt/homebrew/opt/gcc/lib/gcc/current/libgfortran.5.dylib
[…]
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 26.0
      sdk 26.0
   ntools 1
     tool 3
  version 1221.4

means that this shared library can only run on 26 and later (that's the minos field). So that makes it unsuitable (I think) to distribute in wheels, which should run on a large variety of macOS versions.

The version provided for example in conda-forge is built specially for that purpose. See:

$ otool -l /Users/fx/miniforge3/pkgs/libgfortran5-15.2.0-h742603c_1/lib/libgfortran.5.dylib
[…]
Load command 9
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 11.0
      sdk 11.0
   ntools 1
     tool 3
  version 951.9

Now we have minos 11.0 which is the earliest macOS version that supports Apple Silicon, meaning essentially all macOS versions are supported. On x86_64, I think the conda-forge build targets 10.12.

It takes a different approach to building GCC to achieve that, see in what is done in conda-forge/gfortran_impl_osx-64-feedstock#94 for example.

I don't know the policy and relationships of the different python projects, but I feel you have two options at this stage:

use an existing build of gcc/gfortran that is widely compatible, such as conda-forge's
build your own version

The goal here is to build OpenBLAS to run on macos-10.9 and up for x86_64 and macos-11 and up for arm64, so it can be used by NumPy and SciPy for their wheels.

I guess we should explore using miniforge compilers

It seems conda-forge compilers are not the path forward right now, as discussed here. We are planning on dropping macos-x86_64 next year across the Scientific Python ecosystem. So for now in #225 I used the gfortran from the macos-15 image for arm64 and continued with gfortran-11.3 for x86_64.

We are statically linking to libgfortran for the macos builds.

When I look at the arm64 libscipy_openblas64_.dylib, I see this for LC_BUILD_VERSION section.

Load command 9
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 11.0
      sdk 15.0
   ntools 1
     tool 3
  version 1115.7.3

When I look at the x86_64 libscipy_openblas64_.dylib I see this for LC_VERSION_MIN_MACOSX (on the build from #225)

Load command 8
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.9
      sdk 15.0
Load command 9

Will the sdk version be a problem on pre-15 macos?

Will the sdk version be a problem on pre-15 macos?

I don't think so, minos 11.0 should be enough.

I used the gfortran from the macos-15 image for arm64

That has the wrong minos version.

We are statically linking to libgfortran for the macos builds

Can you explain/confirm that? I see shared dylibs in a freshly installed scipy from pypi:

$ ls /Users/fx/miniforge3/envs/test/lib/python3.13/site-packages/scipy/.dylibs
libgcc_s.1.1.dylib  libgfortran.5.dylib libquadmath.0.dylib

Actually, weirdly enough, the libgfortran and libquadmath have 14.0 as minos value:

$ otool -l libgfortran.5.dylib | grep minos
    minos 14.0
$ otool -l libgcc_s.1.1.dylib | grep minos
    minos 11.0
$ otool -l libquadmath.0.dylib | grep minos
    minos 14.0

They come from a wheel that is scipy-1.16.3-cp313-cp313-macosx_14_0_arm64.whl. So I'm more and more confused about what is being shipped, and where it comes from.

That has the wrong minos version.

We set MACOSX_DEPLOYMENT_TARGET=11.0 on arm64. Are you saying that cannot work?

They come from a wheel that is scipy-1.16.3-cp313-cp313-macosx_14_0_arm64.whl

This repo produces the scipy_openblas64 and scipy_openblas32 wheels, the links are to the latest versions on PyPI. SciPy also installs a gfortran compiler in its wheel build since it still has fortran code in the code base. They (apparently) do not statically link.

@fxcoudert

We set MACOSX_DEPLOYMENT_TARGET=11.0 on arm64. Are you saying that cannot work?

That is robust for all the code that is built in the PR, but it won't affect the minos version of what is vendored into the wheel.

There shouldn't be a problem here though. The minos 14.0 is coming from the Accelerate wheels, the corresponding wheel name is macosx_14_0 so they should only support macOS >=14.

@fxcoudert we are shipping two sets of wheels per architecture for both NumPy and SciPy:

x86-64, with vendored OpenBLAS: macOS >=10.13
x86-64, linked against Accelerate NEWLAPACK, macos >=14
arm64, with vendored OpenBLAS: macOS >=11 (numpy) or >=12 (scipy)
arm64, linked against Accelerate NEWLAPACK, macos >=14

Accelerate NEWLAPACK was only introduced in macOS 13.3, and Python wheels currently do not support targeting minor macOS versions, hence >=14.0 was the only option there.

I hope that clarifies it. Regarding libgfortran:

The numpy wheels linked against Accelerate don't need it, no Fortran involved
All the other numpy wheels contain the libgfortran that is re-vendored from whatever is used by scipy-openblas64
all scipy wheels use libgfortran as determined by the complicated dance done in https://github.com/scipy/scipy/blob/b73bb351dd0cc9d6699c72837caf043d0a73df01/tools/wheels/cibw_before_build_macos.sh

Navigation Menu

Repository navigation

Unmaintained GCC/gfortran version is shipped #224

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unmaintained GCC/gfortran version is shipped #224

Description

Activity

mattip commented on Oct 26, 2025

mattip commented on Oct 26, 2025

fxcoudert commented on Oct 26, 2025

mattip commented on Oct 26, 2025

mattip commented on Oct 29, 2025

rgommers commented on Oct 29, 2025

fxcoudert commented on Oct 29, 2025

mattip commented on Oct 30, 2025

rgommers commented on Oct 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions