Control: notfound 1011166 pidgin/2.14.9-2 Control: tags 1011166 patch
On 5/17/22 15:34, Paul Gevers wrote:
I note that the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.
I converted from an ancient compat version to modern debhelper. This brought in multiarch support. Rather than fight it, I just went with that, since the problem looked tractable.
Naively I would have expected it to be picked up, but maybe the /purple-2 in the middle of the path is preventing that.
-- BEGIN RED HERRING -- I would expect it to be picked up.libpurple/plugin.c sets up the search path for that purple-2 directory (which is where all libpurple plugins are installed):
purple_plugins_add_search_path(LIBDIR);
In libpurple/Makefile.am, AM_CPPFLAGS has:
-DLIBDIR=\"$(libdir)/purple-$(PURPLE_MAJOR_VERSION)/\"
This should cause us to find libxmpp.so, the protocol plugin. It then
needs to bring in libjabber.so, an internal library. It should be
finding this with RUNPATH, I believe:
$ readelf -a /usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so | grep -i path0x000000000000001d (RUNPATH) Library runpath: [/usr/lib/x86_64-linux-gnu/purple-2]
If I run: LD_DEBUG=libs pidgin -n
That is indeed what happens:
43864: find library=libjabber.so.0 [0]; searching
43864: search
path=/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell:/usr/lib/x86_64-linux-gnu/purple-2/tls/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls:/usr/lib/x86_64-linux-gnu/purple-2/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/haswell:/usr/lib/x86_64-linux-gnu/purple-2/x86_64:/usr/lib/x86_64-linux-gnu/purple-2
(RUNPATH from file
/usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so)
If I run: LD_DEBUG=libs chatty
It fails:
43926: find library=libjabber.so.0 [0]; searching
43926: search path=/usr/lib/purple-2 (RUNPATH from file
chatty)
43926: trying file=/usr/lib/purple-2/libjabber.so.0
43926: search cache=/etc/ld.so.cache
43926: search
path=/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/glibc-hwcaps/x86-64-v3:/lib/glibc-hwcaps/x86-64-v2:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/glibc-hwcaps/x86-64-v3:/usr/lib/glibc-hwcaps/x86-64-v2:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib
(system search path)
At first glance, it felt like the RUNPATH from chatty was winning over that from libxmpp.so.
-- END RED HERRING --Upon further investigation, the real issue is that chatty is directly linking to libjabber.so, and they're setting a RUNPATH to do it.
chatty's src/meson.build has:
executable('chatty', chatty_sources, resources,
include_directories: src_inc,
dependencies: chatty_deps,
link_with: libchatty.get_static_lib(),
install: true,
install_rpath: purple_plugdir,
)
Note the install_rpath.
and src/purple/meson.build has (manual wrapping added for email):
purple_plugdir = purple_dep.get_pkgconfig_variable('plugindir')
jabber = meson.get_compiler('c').find_library(
'jabber', dirs: purple_plugdir)
In terms of "Who is at fault?", I blame chatty for explicitly linking to
an internal library. However, in fairness, I understand that they have
their reasons and a better solution was never found with upstream (at
least in part because no significant changes are going to go into purple
2 at this point):
https://source.puri.sm/Librem5/chatty/-/issues/266The good news here is that a rebuild of chatty is all that's necessary. A binNMU should be sufficient to fix the bug. I've submitted a request for one, but this was my first time, so I might have done something wrong.
To fix it fully correctly, though, I think we want a versioned Build-Depends to ensure it cannot be built against an old libpurple0 (not that such a thing should happen). And a lintian override needs updating. Here is a MR for that:
https://salsa.debian.org/DebianOnMobile-team/chatty/-/merge_requests/21 -- Richard
OpenPGP_signature
Description: OpenPGP digital signature
