static-haskell-nix
static-haskell-nix | haskell-kafka | |
---|---|---|
7 | 1 | |
389 | 0 | |
- | - | |
7.4 | 0.0 | |
3 months ago | over 3 years ago | |
Nix | Haskell | |
- | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
static-haskell-nix
-
Trying to build a statically linked binary against glibc (Linux)
Using Nix: https://github.com/nh2/static-haskell-nix
- Generating static binary + CI questions
-
GHC reports "Loading static libraries is not supported"
To debug this type of problem (I have to debug linker errors regularly as part of static-haskell-nix):
-
[ANN] Monomer, a GUI library for Haskell
In static-haskell-nix there is currently this PR to enable support for that: https://github.com/nh2/static-haskell-nix/pull/108
- What's all the hype with Nix?
-
Termite Is Obsoleted by Alacritty
I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs.
Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.
> if they could keep that libgtk_static around
Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.
> I'd be interested to hear if static linking GTK even has that many benefits
One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.
Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.
This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.
[1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...
-
Clodl: Turn dynamically linked ELF binaries into self-contained closures
GTK can be statically linked.
Example executable:
https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...
It lost this ability temporarily when switching to Meson, but I fixed it in GTK3 and GTK4. But I just checked and apparently it is broken again:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109746...
haskell-kafka
-
What's all the hype with Nix?
The project was pushed on Github. The readme.md (hopefully) contains all the needed information to run locally and some useful links to nix/stack-with-nix etc.
What are some alternatives?
monomer - An easy to use, cross platform, GUI library for writing Haskell applications.
nixos-config - Personal collection of NixOS config files
haskell.nix - Alternative Haskell Infrastructure for Nixpkgs
nix-cabal-simplest - The simplest Nix + Cabal setup possible, for demo purposes.
Cabal - Official upstream development repository for Cabal and cabal-install
nixpkgs - Nix Packages collection & NixOS
gi-gtk-declarative - Declarative GTK+ programming in Haskell
haskell-nix - Nix and Haskell in production
Windows-10 - Windows 10 Light theme for Linux (GTK)
alacritty - A cross-platform, OpenGL terminal emulator.