Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try producing fully static binaries #138

Open
chshersh opened this issue Jan 30, 2020 · 4 comments
Open

Try producing fully static binaries #138

chshersh opened this issue Jan 30, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request installation

Comments

@chshersh
Copy link
Contributor

Using static-haskell-nix most likely.

@chshersh chshersh added enhancement New feature or request installation labels Jan 30, 2020
@chshersh chshersh added this to the v0.2.0.0: Refinement milestone Jan 30, 2020
@chshersh chshersh self-assigned this Feb 9, 2020
chshersh added a commit that referenced this issue Feb 9, 2020
@chshersh
Copy link
Contributor Author

chshersh commented Feb 9, 2020

I've run out of space locally when trying to produce a statically linked executable. My work can be found in this branch:

But in theory, it should work.

@chshersh
Copy link
Contributor Author

An alternative could be to use Docker and the ghc-musl repository:

As a nice bonus point, the repo contains instructions for both cabal and stack and also supports GHC-8.8, so in theory it should be pretty straightforward to use it.

@chshersh
Copy link
Contributor Author

Okay, Docker works smoothly and without any problems 👍 Looks like it's the way to go. Once we create a release, I will build a statically linked executable and upload it to releases. The only problem now is that the result of the --version command is not nice:

Hit v0.2.0.0
 ➤ Git revision: UNKNOWN
 ➤ Commit date:  UNKNOWN

I believe that this is because the .git folder is not copied. But I hope there's a flag to copy some additional folders, shouldn't be a big problem.

@vrom911
Copy link
Member

vrom911 commented Feb 10, 2020

That is fantastic news! Thanks for working on this. The next release is going to be 🔥

@vrom911 vrom911 self-assigned this Mar 21, 2020
@vrom911 vrom911 assigned vrom911 and unassigned vrom911 Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request installation
Projects
None yet
Development

No branches or pull requests

2 participants