Update the dynamic libnotify check for the newer soname
See bug https://bugzilla.redhat.com/show_bug.cgi?id=693362
The xchat code currently does:
nn_mod = g_module_open ("libnotify", G_MODULE_BIND_LAZY);
which looks for "libnotify" which fails, then "libnotify.so" which fails, then
"libnotify.la" which fails.
The above then looks for "/usr/lib64/libnotify.so".
On developer systems with libnotify-devel installed, this file exists, so it
happily loads libnotify support for us. However, on user systems, it does not
exist which leads to that g_module_open call outright failing. This explains
why it appeared to be working for me and presumably Owen too, but not for
the reporter.
Then, the xchat code tries to load the (wrong) versioned module. Naturally,
that fails, too. At that point, it then falls back to use notify-send.
I'm not sure the motivations for dynamically loading the library instead of
linking directly, but I think a correct minimalistic fix is to do:
- nn_mod = g_module_open ("libnotify", G_MODULE_BIND_LAZY);
+ nn_mod = g_module_open ("libnotify.so.4", G_MODULE_BIND_LAZY);
This adds the newest versioned library at the top of the check, and still keeps
the old versioned library. However, it also removes the devel only library
from the list which reduces the chances that developers will be blind to this
issue in the future. There's no real reason to look there anyway since users
just won't have that installed.
But this is all really just a hack. The proper fix should be simply to link
directly against libnotify. notify-send is part of libnotify anyway so it is
entirely reasonable to expect systems that have notify-send installed to also
have libnotify itself installed.