Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require glib2 version with g_once_init_enter_pointer symbol #1645

Open
wants to merge 1 commit into
base: dnf-4-master
Choose a base branch
from

Conversation

ppisar
Copy link
Contributor

@ppisar ppisar commented Feb 27, 2024

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 libdnf built against new glib2 but not upgrading glib2 at the same time will break dynamic linking of libdnf:

    Traceback (most recent call last):
      File "/usr/bin/dnf-3", line 61, in <module>
	from dnf.cli import main
      File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in <module>
	import dnf.base
      File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in <module>
	import libdnf.transaction
      File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line 14, in <module>
	from . import conf
      File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10, in <module>
	from . import _conf
    ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_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.

This issue is specific to not fully upgraded Fedora 40--41. 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

https://bugzilla.redhat.com/show_bug.cgi?id=2265336

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 libdnf built against new glib2 but
not upgrading glib2 at the same time will break dynamic linking of
libdnf:

    Traceback (most recent call last):
      File "/usr/bin/dnf-3", line 61, in <module>
	from dnf.cli import main
      File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in <module>
	import dnf.base
      File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in <module>
	import libdnf.transaction
      File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line 14, in <module>
	from . import conf
      File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10, in <module>
	from . import _conf
    ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_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.

This issue is specific to not fully upgraded Fedora 40--41.
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

https://bugzilla.redhat.com/show_bug.cgi?id=2265336
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant