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.
Kevin Kofler
--
_______________________________________________
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
