Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Ivo De Decker
ivodd at debian.org
Sat Apr 10 21:13:13 BST 2021
On Thu, Feb 18, 2021 at 03:33:23PM +0000, Simon McVittie wrote:
> > I'd rather think that the situation happened because
> > elpa-pdf-tools-server links both to libpoppler and libpoppler-glib:
> > the rebuild against poppler 20.09.0 (i.e. libpoppler102) make
> > elpa-pdf-tools-server link to libpoppler102 (forcing the newer
> > dependency to it), and setting an old dependency for libpoppler-glib
> > because there is no need for a newer version.
> So elpa-pdf-tools-server is linked to libpoppler-glib, and because the
> (parts of the) libpoppler-glib API that it uses has not changed for a
> while, it is happy with an old version; but then during a partial
> upgrade, it can get this
> \- old libpoppler-glib
> | \- libpoppler95
> \- libpoppler102
> and the two copies of libpoppler fight?
> That seems entirely plausible, and I don't immediately see a way to
> fix it without adding Breaks (which would force a lockstep upgrade,
> somewhat defeating the purpose of SONAMEs).
> GNOME had similar issues during the libffi transition, where gjs' direct
> use of libffi conflicted with its indirect use via GLib, and I think we
> ended up adding Breaks to force the broken combinations not to happen.
There are 2 other packages in bullseye that depend on both libpoppler and
libpoppler-glib: gambas3-gb-poppler and inkscape.
This issue is also present in inkscape (I didn't try to reproduce it with
gambas3-gb-poppler, but I guess the situation is similar):
Install inkscape on a buster system. The pdf David attached can be opened
without issue. Upgrade only inkscape to bullseye (letting apt pull in the
dependencies, which include libpoppler102 but not the newer libpoppler-glib8).
When opening the pdf inkscape closes with an error, and the kernel reports:
inkscape: segfault at 9 ip 00007fad9e3e1d3e sp 00007fff5127ae30 error 4 in libpoppler-glib.so.8.10.0[7fad9e3c4000+27000]
Installing the new libpoppler-glib8 fixes the issue.
A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
have an elegant way to handle this automatically at build time to make sure
the dependencies are correct, without having to add them manually.
More information about the Pkg-freedesktop-maintainers