Description of problem: <notting> mclasen: (gwibber:7830): libnotify-WARNING **: Missing symbol 'gdk_screen_make_display_name' <- is this an intentional removal? <mclasen> notting: I still see it here, in 2.x and in 3 <notting> oh cute libnotify isn't linked against gtk2 <mclasen> no it relies on the app linking against one version of gtk now <notting> mclasen: so, if you're in python, you must import them in a certain order? <mclasen> perhaps ? I don't know much about python, to put it mildly <walters> notting: i think so, yes <notting> walters: didn't help As said, swapping the include order in gwibber/microblog/util/__init__.py:142 didn't help. Version-Release number of selected component (if applicable): libnotify-0.5.1-1.fc14.x86_64 gwibber-2.31.4-1.fc14.noarch How reproducible: 100% Steps to Reproduce: 1. Run gwibber from a text console
Uhhh... maybe Dave Malcolm can shed some light here.
Off the top of my head, this sounds like a "gold" change: https://fedoraproject.org/wiki/GoldIncompatibilities
I'm confused. Both _pynotify.so, and pygtk2 are linked against gtk2.
(In reply to comment #2) > Off the top of my head, this sounds like a "gold" change: > https://fedoraproject.org/wiki/GoldIncompatibilities We're not using gold, unless I missed something.
Minimal reproducer (on an x64_64 rawhide box): $ python -c "import pynotify; pynotify.init('foo')" (-c:1940): libnotify-WARNING **: Missing symbol 'gdk_screen_make_display_name' $ rpm -qf /usr/lib64/python2.7/site-packages/gtk-2.0/pynotify/_pynotify.so notify-python-0.1.1-14.fc15.x86_64 $ rpm -qf /usr/lib64/libnotify.so.1 libnotify-0.5.1-1.fc14.x86_64 $ eu-readelf -s /usr/lib64/libnotify.so.1|grep gdk_screen_make 89: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF gdk_screen_make_display_name libnotify uses "gdk_screen_make_display_name" but isn't linked against anything providing it. Importing pygtk first doesn't help: $ python -c "import gtk ; import pynotify; pynotify.init('foo')" (-c:1945): libnotify-WARNING **: Missing symbol 'gdk_screen_make_display_name' $ python -c "import gtk.gdk ; import pynotify; pynotify.init('foo')" (-c:20551): libnotify-WARNING **: Missing symbol 'gdk_screen_make_display_name' $ rpm -q pygtk2 gtk2 pygtk2-2.17.0-7.fc15.x86_64 gtk2-2.21.6-1.fc15.x86_64 $ eu-readelf -d /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/_gtk.so|grep NEEDED | grep gtk NEEDED Shared library: [libgtk-x11-2.0.so.0] $ eu-readelf -s /usr/lib64/libgtk-x11-2.0.so|grep gdk_screen_make (no output) $ eu-readelf -d /usr/lib64/libgtk-x11-2.0.so|grep gdk NEEDED Shared library: [libgdk-x11-2.0.so.0] NEEDED Shared library: [libgdk_pixbuf-2.0.so.0] $ eu-readelf -s /usr/lib64/libgdk-x11-2.0.so|grep gdk_screen_make 1215: 000000386ec6eb30 155 FUNC GLOBAL DEFAULT 11 gdk_screen_make_display_name so this is the DSO containing the implementation.
Given that libnotify is using gdk, why isn't it linked against gdk? Is the idea to support being linked against different parallel-installable GTK stacks?
Trying to resolve this at the python level by importing things in a contrived order seems fragile at best, and doesn't seem to work: >>> import gtk.gdk >>> s = gtk.gdk.Screen() >>> s.make_display_name() 'localhost:10.0' >>> import pynotify; pynotify.init('foo') (.:31451): libnotify-WARNING **: Missing symbol 'gdk_screen_make_display_name' False
I believe it's linked this way so that it can work in either gtk2 or gtk3 apps.
(In reply to comment #7) > Trying to resolve this at the python level by importing things in a contrived > order seems fragile at best, and doesn't seem to work: > >>> import gtk.gdk > >>> s = gtk.gdk.Screen() > >>> s.make_display_name() > 'localhost:10.0' > >>> import pynotify; pynotify.init('foo') > > (.:31451): libnotify-WARNING **: Missing symbol 'gdk_screen_make_display_name' > False Running under gdb and putting a breakpoint on "gdk_screen_make_display_name", it hits the breakpoint at the call to "s.make_display_name()". I notice that when it does so, it's reported by gdb as being within IA__gdk_screen_make_display_name rather than gdk_screen_make_display_name as in: #0 IA__gdk_screen_make_display_name (screen=0xa1ace0 [GdkScreenX11]) at gdkscreen-x11.c:1286
libgdk-x11-2.0.so has ELF symbol gdk_screen_make_display_name but DWARF symbol (that is from debuginfo) IA__gdk_screen_make_display_name. GDB prefers DWARFs symbols to print but resolves both. Unaware how is it related to libnotify, though.
See sys.setdlopenflags: if you want extension modules to share symbols, setdlopenflags(...) setdlopenflags(n) -> None Set the flags used by the interpreter for dlopen calls, such as when the interpreter loads extension modules. Among other things, this will enable a lazy resolving of symbols when importing a module, if called as sys.setdlopenflags(0). To share symbols across extension modules, call as sys.setdlopenflags(ctypes.RTLD_GLOBAL). Symbolic names for the flag modules can be either found in the ctypes module, or in the DLFCN module. If DLFCN is not available, it can be generated from /usr/include/dlfcn.h using the h2py script. >>> import ctypes >>> import sys >>> sys.setdlopenflags(sys.getdlopenflags() | ctypes.RTLD_GLOBAL) >>> import gtk >>> import pynotify >>> pynotify.init('foo') True
>>> n = pynotify.Notification(summary='foo') >>> n.show() True ...and a notification appeared
It looks like if libnotify is going to be shipped in this half-linked state, then notify-python's pynotify.__init__.py needs to be patched to add: import ctypes import sys sys.setdlopenflags(sys.getdlopenflags() | ctypes.RTLD_GLOBAL) before: from _pynotify import * (probably with a detailed comment explaining why!)
(In reply to comment #13) > It looks like if libnotify is going to be shipped in this half-linked state, > then notify-python's pynotify.__init__.py needs to be patched to add: > import ctypes > import sys > sys.setdlopenflags(sys.getdlopenflags() | ctypes.RTLD_GLOBAL) Need to add an: import gtk here as well > before: > from _pynotify import * > > (probably with a detailed comment explaining why!)
As a test, I hacked up /usr/lib64/python2.7/site-packages/gtk-2.0/pynotify/__init__.py on my rawhide VM to read: --- BEGIN QUOTE --- import ctypes import sys sys.setdlopenflags(sys.getdlopenflags() | ctypes.RTLD_GLOBAL) import gtk from _pynotify import * --- END QUOTE --- With that content, it seems to work: >>> import pynotify >>> pynotify.init('foo') True >>> n = pynotify.Notification(summary='foo') >>> n.show() True (notification appeared)
gwibber-2.31.93-1.847bzr.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/gwibber-2.31.93-1.847bzr.fc13
gwibber-2.31.93-1.847bzr.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/gwibber-2.31.93-1.847bzr.fc12
notify-python-0.1.1-15.fc14,gwibber-2.31.93-1.847bzr.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/notify-python-0.1.1-15.fc14,gwibber-2.31.93-1.847bzr.fc14
gwibber-2.31.93-1.847bzr.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gwibber'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gwibber-2.31.93-1.847bzr.fc12
gwibber-2.31.93-1.847bzr.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
gwibber-2.31.93-1.847bzr.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
notify-python-0.1.1-15.fc14, gwibber-2.31.93-1.847bzr.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
I'm having a similar problembut with the libnotify gem (ruby). It uses other gem called ffi to use libnotify.so.1 and it seems that dont work on fedora. it give the same error. https://github.com/splattael/libnotify/issues/4