[Debian-on-mobile-maintainers] Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0

[Richard Laager]

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 path
  0x000000000000001d (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/266

The 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-on-mobile-maintainers/attachments/20220518/d2d1cbe8/attachment.sig>