purescript
Build fully static compiler binary using ghc-musl
Description of the change
Closes #4572.
Checklist:
- [x] Added a file to CHANGELOG.d for this PR (see CHANGELOG.d/README.md)
- [x] Added myself to CONTRIBUTORS.md (if this is my first contribution)
- [x] Linked any existing issues or proposals that this pull request should close
- [x] Updated or added relevant documentation
- [x] Added a test for the contribution (if applicable)
Next task to do on my end is to verify the licenses of the various dependencies that we're using to make sure that we can statically link against them. I'm on a Mac at the moment so I can't test the static build of the compiler on the daily but it passing all tests and building the package set is very promising.
@purefunctor Regarding statically linked Linux binaries:
GMP licensing restrictions
The regular
GHC musl images produce binaries linked against the GNU Multiple Precision Arithmetic Library (GMP), which is used by default by theinteger-gmplibrary to provide a big-integer implementation for Haskell.Unlike most Haskell code, which is licensed under the permissive BSD3 license, the GMP library is licensed under LGPL. This means resulting statically linked binaries must be provided with source code or object files.
If that is not acceptable for your situation, use images with the
int-nativesubtag. These images provide a GHC that links against the Haskell-native big-integer backend and produces statically linked binaries that and are not subject to GMP's licensing restrictions.
:information_source: Available for versions 9.6.7, 9.8.4, 9.10.1, 9.12.2 and later.
– https://github.com/benz0li/ghc-musl#gmp-licensing-restrictions
Cross reference:
-
FAQ - The Haskell Tool Stack > What is licensing restrictions on Windows?
-
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. [...]
Hi @benz0li, many thanks for the information about licensing and apologies for the late response.
Following suit from stack and pandoc, I believe the next steps would be:
- to specify that Linux builds may statically link against GMP
- to add a copy of LGPL/GPL to the
LICENSEfile - to specify links for the compiler's and GMP's source code
After which we should be ready to distribute statically-linked binaries.
Thoughts on this @rhendric @f-f ?
This PR is now ready for review! I'm also happy to take on updating https://github.com/purescript/npm-installer (and other distributions) to point to the new static binaries.
@purefunctor I have updated the CI requirements to include the new jobs, so the path ahead is all green - are we good to merge?
Let's go for it! I'll make a post on the discourse soon
On Thu, Jun 26, 2025, 02:54 Fabrizio Ferrai @.***> wrote:
f-f left a comment (purescript/purescript#4573) https://github.com/purescript/purescript/pull/4573#issuecomment-3005817886
@purefunctor https://github.com/purefunctor I have updated the CI requirements to include the new jobs, so the path ahead is all green - are we good to merge?
— Reply to this email directly, view it on GitHub https://github.com/purescript/purescript/pull/4573#issuecomment-3005817886, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP46GXFQRXZRX4Q3T6CGSF33FLV5RAVCNFSM6AAAAAB2ZXJSMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBVHAYTOOBYGY . You are receiving this because you were mentioned.Message ID: @.***>