The libmodulemd package
glib2-2.79.0-2.fc40 added g_once_init_enter_pointer symbol and started
to implant a reference on the symbol into applications via
macros/in-lined functions included from glib2 header files. As
a result, people upgrading to libmodulemd built against new glib2 but
not upgrading glib2 at the same time will break dynamic linking of
libmodulemd:
# dnf5 install NetworkManager
dnf5: symbol lookup error: /lib64/libmodulemd.so.2: undefined symbol: g_once_init_leave_pointer
If glib2 versioned its symbols, rpm-build would inject an RPM
dependency on the new glib2 versioned SONAME. However, this is not
true, so we need to add a dependency on a minimal glib2 version
manually.
Because this issue is specific to not fully upgraded Fedora 40--41,
I will not post it to the upstream. This issue materializes in real
life when mock installs a new libdnf into a bootstrap image based on
a container image created before glib2-2.79.0-2.fc40 (bug #2265336).
|
||
|---|---|---|
| tests | ||
| .gitignore | ||
| .make_packit_specfile.sh | ||
| .packit.yml | ||
| gating.yaml | ||
| gpgkey-E3F42FCE156830A80358E6E94FD1AEC3365AF7BF.gpg | ||
| libmodulemd.spec | ||
| modulemd-2.15.0-build-Move-computing-gtk-doc-module-paths-to-the-che.patch | ||
| modulemd-2.15.0-doc-Adapt-GLib-documentation-path-to-GLib-2.79.0.patch | ||
| README.md | ||
| README.packit | ||
| sources | ||
libmodulemd
C Library for manipulating module metadata files See https://pagure.io/modulemd for more details.