Skip to content

Change build and link to take only the needed routines from libgfortran - #282

Merged
mattip merged 7 commits into
MacPython:mainfrom
mattip:no-libgfortran
Oct 13, 2026
Merged

mattip merged 7 commits into
MacPython:mainfrom
mattip:no-libgfortran

Conversation

@mattip

@mattip mattip commented Oct 8, 2026 •

Copy link
Copy Markdown
Collaborator
  • I updated the package version in pyproject.toml and made sure the first 3 numbers match ./openblas_commit.txt. If I did not update ./openblas_commit.txt, I incremented the wheel build number (i.e. 0.3.29.0.0 to 0.3.29.0.1)

Note: update ./openblas_commit.txt with cd OpenBLAS; git describe --tags --abbrev=8 > ../openblas_commit.txt

Fixes #281.

We only use a few objects from libgfortran, and do not use libquadmath at all. It is linked to be libgfortran in the manylinux_2_28 images' gfortran, in manylinux_2_39 libquadmath is no longer linked. This PR uses the objects from libgfortran.a on linux which shrinks the wheel and makes the entire package's licence simpler.

@rgommers

rgommers commented Oct 8, 2026

Copy link
Copy Markdown
Collaborator

This seems like a good idea in principle, the gain is fairly large. The first question that comes to mind is licensing: just to confirm, we're dropping the problematic libquadmath license but keeping the libgfortran one, right (because static linking)?

The replacement code for those few symbols probably should be kept separate, since that likely should be licensed LGPL or even GPL (not sure without checking), unless it's a cleanroom reimplementation.

@mattip

mattip commented Oct 8, 2026

Copy link
Copy Markdown
Collaborator Author

The license extension for libgfortran seems to say "as long as you get the pieces when linking your project to this library unmodified with gcc do whatever you want". We do exactly that: link libgfortran.a to our build of openblas, i.e. pull out the few routines we use as binary objects.

@mattip

mattip commented Oct 9, 2026

Copy link
Copy Markdown
Collaborator Author

Since the last build, the windows-arm image updated so the build.bat script, which had hardcoded vs2022, failed. Fixed in 985ffc6. @rgommers I think pulling a few object files out of libgfortran.a is allowed in the gcc extension to the GPL license of libgfortran, what do you think?

@rgommers

Copy link
Copy Markdown
Collaborator

@mattip agreed that static linking in the way done here is allowed, and that the libgfortran license can then be dropped.

The fallback behavior in this PR is the main question mark indeed - if that could be removed, then all GPL/LGPL license content can be dropped unconditionally.

@mattip

mattip commented Oct 12, 2026

Copy link
Copy Markdown
Collaborator Author

I removed the fallback by downloading the static libgfortran.a from conda forge for macos, the linux builds get it from gcc. So I refactored to remove the fallback, removed the libquadmath license, and unified the license.txt to a single LICENSE_posix.txt.

@rgommers

Copy link
Copy Markdown
Collaborator

Nice. Probably just move ahead here, unless you think I should review some part in more detail. I'm kinda swamped after a week off from regular OSS activity.

@mattip
mattip merged commit 5cfb9c1 into MacPython:main Oct 13, 2026
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Shrink the wheel by not shipping libgfortran.so

2 participants