Static linking of wlroots

[kennylevinsen]

wlroots is generally shipped as a shared library. This presents issues for packaging, as packagers must wait for all packaged wlroots-based compositors to be updated before they can bump wlroots, which in turn means that compositor releases depending on the latest release of wlroots end up waiting on other compositors to update. An example of such packaging issues can be seen in alpine here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20264.

The simplest way to solve this would be for compositors to ship wlroots as a statically linked subproject, bypassing the need for a shared libwlroots.so and thus allowing compositors to use whichever revision they support.

Current blockers for friction-less statically linked subproject:

1. Avoid wlroots installation when built as a subproject. See: subproject installs when project using it installs mesonbuild/meson#2550, which was resolved with a user flag rather than a meson.build option. This could be worked around in our meson.build file.
2. Policy or solution for internal symbol collisions, such as get_current_time_msec conflicting between sway and wlroots (Static library contains private symbols #1892, get_current_time_msec conflicts with wlroots symbol sway#5514).

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2952

[emersion]

I agree static linking makes sense for something like wlroots.

Regarding (1), packagers will need to add logic to setup the subproject anyways, so I think it's fine to ask them to use the --skip-subprojects flag.

[emersion]

(Maybe we should update the wiki page for packagers once we have (2) addressed.)

[kennylevinsen]

Reopened due to revert.

[ericonr]

Please don't encourage projects to ship internal wlroots versions. This makes it harder to apply global patches and adds the need for distros to track which wlroots version each package is using. Furthermore, wlroots makes clear releases and bumps soname when it has ABI breaks: this means there are well tested points in time (instead of each project picking a random point in time to tag a release) and that two versions of the library can co-exist. Distros rushing to update things can

• pick up/develop patches for each compositor
• create a wlroots0.x package for the packages that haven't been updated yet (which I see is what was implemented in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20264#note_160337, and makes this discussion somewhat unnecessary)

[emersion]

This issue is not about making it easy to bundle a random wlroots commit in a compositor. This issue is about making it easy to statically link to a wlroots release.

[ammen99]

This issue is not about making it easy to bundle a random wlroots commit in a compositor. This issue is about making it easy to statically link to a wlroots release.

What is the benefit of statically linking to a system-wide static version of wlroots? To me, the only benefit of static linking is if the compositor has the library as a subproject and links to it statically.

[emersion]

The benefit is to allow distributing compositors that don't use the same wlroots version, e.g. one compositor depends on wlroots 0.13.0 and the other depends on 0.14.0. The static wlroots lib doesn't need to be installed system-wide.

We still want to urge compositors to upgrade to the latest wlroots. But we also want to reduce the upgrade burden distributions have.