On Mon, Jun 30, 2025 at 3:11 AM Kevin Kofler via devel <devel@lists.fedoraproject.org> wrote: > > Hi, > > while packaging GTK 4.19.2 with the GLES2 patchset from my GitHub fork, I > ran into a file list error, which made me stumble upon this upstream GTK > commit: > https://github.com/GNOME/gtk/commit/e8694e0e7f71aa2e1a3ac4299ab675170a051145 > > (I am linking to the GitHub mirror because the GNOME GitLab has Anubis > configured in such a way that it does not work at all in my browser, unlike > all the other sites running Anubis that I have run into. The commit is an > upstream commit from GNOME GitLab.) > > Do not let the wording "Let …" in the commit message fool you. There is no > option there, the backends are now ALWAYS static rather than modules. So > "Force …" would be more accurate. > > What this means is that any GTK application in Fedora will now always load > GStreamer and CUPS libraries on startup, no matter whether it actually does > any media playback/capture and/or any printing. And worse, if multiple > backends are enabled, they will ALL be statically built in and hence loaded > on startup along with any libraries they depend on. (E.g., the "file" > printing backend is also built in now, though that one at least does not > drag in any additional external libraries.) This unnecessary linking of > large libraries (such as GStreamer and CUPS) means a huge waste of RAM and > an increased potential for subtle bugs such as symbol conflicts. All this > just because Android does not or poorly support dlopen, an Android-specific > issue that should not affect us. > > The way Qt handles this is that ALL plugins can OPTIONALLY be statically > compiled in, which is done on Android and iOS, and sometimes on macOS, but > most definitely not in GNU/Linux distribution packages. Why has GTK decided > to hardcode the static linking instead of either making it an option for the > packager or deciding it automatically based on the target (Android = static, > GNU/Linux = dynamic)? IMHO, it is not acceptable. > > I could revert the offending commit in my fork, but that would not help all > the users using the stock Fedora GTK, and it is also not what the fork is > supposed to be for. >
You'd have to take it up with the upstream GTK developers in the merge request this occurred in: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8522 -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
