Repository navigation
Change build and link to take only the needed routines from libgfortran - #282
Conversation
|
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 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. |
|
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 |
|
@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. |
|
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. |
|
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. |
./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.txtwithcd OpenBLAS; git describe --tags --abbrev=8 > ../openblas_commit.txtFixes #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.aon linux which shrinks the wheel and makes the entire package's licence simpler.