static-haskell-nix VS wlroots

Using Nix: https://github.com/nh2/static-haskell-nix

To debug this type of problem (I have to debug linker errors regularly as part of static-haskell-nix):

In static-haskell-nix there is currently this PR to enable support for that: https://github.com/nh2/static-haskell-nix/pull/108

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...

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...

>barrier has been unmaintained for a long time.

As if not having new features added for 2 years makes it stop working? barrier is perfectly fine on normal linux desktop installs. I actually use synergy 1.x personally which has been "unmaintained" for much, much longer. Except synergy 1.x will compile and run on anything from windows 98 to ubuntu 5 to debian 12. You can't get a waynergy or inputleap to compile on an OS more than 2 years old. And even then, as you say, it's crapshoot if the particular wayland will have libei; many like sway are actively hostile to it and never will: https://github.com/swaywm/wlroots/issues/2378

It looks like they actually patched it to filter those modes out, so presumably it worked out of the box and was considered undesirable: https://github.com/swaywm/wlroots/issues/3038

I haven't experienced any of those. The video game performance hit may be due to vsync, but I don't play games so I haven't noticed.

You can however use tinywl. It is an example Wayland compositor that can't do more than displaying one application.

Sway/wlroots has implemented this, but I can't find any discussion for KDE.

wlroots is archived on github. Is it abandoned? Just saying, that only means they moved git hosts :-D

A lot of compositors are based no the wlroots lirbary. So they are still sharing the development effort and have a common base, its just in the form of a library rather than a display server.

gamescope use wlroots