Hi,
On Wed, 2022-05-18 at 03:04 -0500, Richard Laager wrote:
> 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
>
thanks for the thorough analysis!
> The good news here is that a rebuild of chatty is all that's
> necessary.
Indeed. I noticed this while preparing the upgrade to the latest
version.
> 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
Thanks for the patch! I'll upload a fixed version soon.
Evangelos
>
> --
> Richard
> _______________________________________________
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
