Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
On Sunday, May 14, 2023 3:20:39 PM CEST Andreas Metzler wrote: > Something like attached patch. https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1425 /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
On 2023-05-07 Andreas Metzler wrote:
[...]
> The only proper fix would be to use versioned symbols for libpoppler
> (and libpoppler-glib while we are at it). This should not be rocket
> science, just tie it to the soname.
> But that needs to happen upstream.
Something like attached patch.
cu Andreas
Description: Use symbol versioning for libpoppler
.
This needs to be applied upstream when the soname is bumped.
Author: Andreas Metzler
Origin: vendor
Bug-Debian: https://bugs.debian.org/969907
Forwarded: no
Last-Update: 2023-05-14
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -572,16 +572,31 @@ ADD_GPERF_FILE(TimesBoldWidths)
ADD_GPERF_FILE(TimesBoldItalicWidths)
ADD_GPERF_FILE(TimesItalicWidths)
ADD_GPERF_FILE(TimesRomanWidths)
ADD_GPERF_FILE(ZapfDingbatsWidths)
+set(POPPLER_SOVERSION_NUMBER "126")
+
+set(LINKER_SCRIPT "${CMAKE_BINARY_DIR}/libpoppler.map")
+configure_file(
+"${CMAKE_SOURCE_DIR}/poppler/libpoppler.map.in"
+${LINKER_SCRIPT})
+
if(MSVC)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
endif()
-add_library(poppler ${poppler_SRCS})
+add_library(poppler ${poppler_SRCS} ${LINKER_SCRIPT})
generate_export_header(poppler BASE_NAME poppler-private EXPORT_FILE_NAME "${CMAKE_CURRENT_BINARY_DIR}/poppler_private_export.h")
-set_target_properties(poppler PROPERTIES VERSION 126.0.0 SOVERSION 126)
+set_target_properties(poppler PROPERTIES
+ VERSION ${POPPLER_SOVERSION_NUMBER}.0.0
+ SOVERSION ${POPPLER_SOVERSION_NUMBER})
+
+if(UNIX AND (NOT APPLE))
+ set_target_properties(poppler PROPERTIES
+ LINK_OPTIONS LINKER:--version-script=${LINKER_SCRIPT})
+endif()
+
if(MINGW AND BUILD_SHARED_LIBS)
get_target_property(POPPLER_SOVERSION poppler SOVERSION)
set_target_properties(poppler PROPERTIES SUFFIX "-${POPPLER_SOVERSION}${CMAKE_SHARED_LIBRARY_SUFFIX}")
endif()
target_link_libraries(poppler LINK_PRIVATE ${poppler_LIBS})
--- /dev/null
+++ b/poppler/libpoppler.map.in
@@ -0,0 +1,4 @@
+POPPLER_@POPPLER_SOVERSION_NUMBER@ {
+ global:
+*;
+};
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
On 2021-02-18 Simon McVittie wrote: [...] > 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 > elpa-pdf-tools-server > \- 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). [...] Hello, The only proper fix would be to use versioned symbols for libpoppler (and libpoppler-glib while we are at it). This should not be rocket science, just tie it to the soname. But that needs to happen upstream. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Hi, On Thu, Feb 18, 2021 at 03:33:23PM +, 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 > > elpa-pdf-tools-server > \- 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[9032]: segfault at 9 ip 7fad9e3e1d3e sp 7fff5127ae30 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. Cheers, Ivo
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
On Thu, 18 Feb 2021 at 12:06:58 +0100, Pino Toscano wrote: > In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto: > > > In Cairo and Pango (which have a similar structure with multiple binary > > > packages making use of each other's implementation details), I added a > > > debian/shlibs.local to make sure the binary packages all get lockstep > > > dependencies. I think the same technique would be appropriate here. See > > > attached. > > I honestly do not understand how this is even a problem, considering I > fixed this more than 5 years ago: > https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110 Sorry, I didn't spot that the interdependencies were already strict. I'll close the MR. > 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 elpa-pdf-tools-server \- 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. > Another contributing factor is that emacs-pdf-tools "abuses" the > libpoppler-glib internals, see server/poppler-hack.cc. I don't know > why it does that, and I'd rather see the actual issues fixed in > libpoppler-glib. That does look like emacs-pdf-tools is doing things that aren't guaranteed to work, yes, and the solution is indeed to improve libpoppler-glib to do what emacs-pdf-tools needs (and then make emacs-pdf-tools depend on the newer version instead of working around older versions). smcv
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Hi Simon, In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto: > Control: retitle 969907 epdfinfo crashing with mismatched libpoppler102 and > libpoppler-glib8 > Control: tags 969907 + patch > > Sorry, this reply should have gone to the clone in libpoppler-glib8, > not to the archived original bug in epdfinfo (which I don't think was > ever really an epdfinfo bug). > > On Mon, 15 Feb 2021 at 12:03:35 +, Simon McVittie wrote: > > I don't think this is actually about whether libpoppler-glib added new ABI > > without bumping the shlibs version - it has a .symbols file that tracks > > the version in which each public symbol was added. > > > > Instead, I think this is about private symbols and partial > > upgrades. libpoppler102 and libpoppler-glib8 come from the same > > source package, so libpoppler-glib8 is very likely to make assumptions > > about private implementation details of the corresponding version of > > libpoppler102; many of the source files glib/*.cc that get compiled into > > libpoppler-glib8 have #include "poppler-private.h". This is fine if > > everyone does an `apt upgrade` with no pinning, but breaks down if people > > do arbitrary partial upgrades with pinning or interactively (leading to a > > "Frankendebian" system). > > > > If the upstream developers of poppler are asked to support a system where > > libpoppler102 and libpoppler-glib8 are at different versions, I'm pretty > > sure the first thing they will say is "don't". I think the same is > > appropriate for downstreams. Yes, this is correct. > > In Cairo and Pango (which have a similar structure with multiple binary > > packages making use of each other's implementation details), I added a > > debian/shlibs.local to make sure the binary packages all get lockstep > > dependencies. I think the same technique would be appropriate here. See > > attached. I honestly do not understand how this is even a problem, considering I fixed this more than 5 years ago: https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110 and indeed: $ apt-cache show libpoppler-glib8 Package: libpoppler-glib8 Source: poppler Version: 20.09.0-3.1 [...] Depends: libpoppler102 (= 20.09.0-3.1), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2) [...] So the strict dependency is already in place. If I check the version that was reported in the bug report, I see: $ debsnap -d . libpoppler-glib8 -a amd64 0.85.0-2 $ dpkg -I libpoppler-glib8_0.85.0-2_amd64.deb Package: libpoppler-glib8 Source: poppler Version: 0.85.0-2 Depends: libpoppler95 (= 0.85.0-2), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2) 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. This was also a problem in case there was an incomplete dist-upgrade to the newer poppler, so the newer libpoppler was pulled in but the newer libpoppler-glib not. I remember having seen this in the past (when I used to maintain poppler), but it happened once and indeed it was due to an incomplete dist-upgrade. IMHO this will not happen in oldstable->stable dist-upgrades, as everything will be build with the newer libraries, and hopefully the dist-upgrade will be done fully. Another contributing factor is that emacs-pdf-tools "abuses" the libpoppler-glib internals, see server/poppler-hack.cc. I don't know why it does that, and I'd rather see the actual issues fixed in libpoppler-glib. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Control: retitle 969907 epdfinfo crashing with mismatched libpoppler102 and
libpoppler-glib8
Control: tags 969907 + patch
Sorry, this reply should have gone to the clone in libpoppler-glib8,
not to the archived original bug in epdfinfo (which I don't think was
ever really an epdfinfo bug).
On Mon, 15 Feb 2021 at 12:03:35 +, Simon McVittie wrote:
> I don't think this is actually about whether libpoppler-glib added new ABI
> without bumping the shlibs version - it has a .symbols file that tracks
> the version in which each public symbol was added.
>
> Instead, I think this is about private symbols and partial
> upgrades. libpoppler102 and libpoppler-glib8 come from the same
> source package, so libpoppler-glib8 is very likely to make assumptions
> about private implementation details of the corresponding version of
> libpoppler102; many of the source files glib/*.cc that get compiled into
> libpoppler-glib8 have #include "poppler-private.h". This is fine if
> everyone does an `apt upgrade` with no pinning, but breaks down if people
> do arbitrary partial upgrades with pinning or interactively (leading to a
> "Frankendebian" system).
>
> If the upstream developers of poppler are asked to support a system where
> libpoppler102 and libpoppler-glib8 are at different versions, I'm pretty
> sure the first thing they will say is "don't". I think the same is
> appropriate for downstreams.
>
> In Cairo and Pango (which have a similar structure with multiple binary
> packages making use of each other's implementation details), I added a
> debian/shlibs.local to make sure the binary packages all get lockstep
> dependencies. I think the same technique would be appropriate here. See
> attached.
>
> I'm increasingly tempted to open a debhelper feature request asking for
> dh_shlibdeps to strengthen intra-source-package dependencies to be in
> lockstep by default, because this seems to be more common than strict
> separation.
>From bc7c009360869d8985462bab43fc24b1685df08a Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Mon, 15 Feb 2021 11:53:51 +
Subject: [PATCH] d/shlibs.local: Upgrade all binary packages in lockstep
Like many projects where one source package builds multiple binary
packages, poppler has private headers that share non-public interfaces
between its binary packages. Upgrading one binary package from this
source without upgrading the others is not something that its upstream
developers are ever going to test or support, and neither should we.
Closes: #969537
---
debian/changelog| 12
debian/shlibs.local | 4
2 files changed, 16 insertions(+)
create mode 100644 debian/shlibs.local
diff --git a/debian/changelog b/debian/changelog
index d65fa9f..54c96af 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+poppler (20.09.0-3.2) UNRELEASED; urgency=medium
+
+ * d/shlibs.local: Upgrade all binary packages in lockstep.
+Like many projects where one source package builds multiple binary
+packages, poppler has private headers that share non-public interfaces
+between its binary packages. Upgrading one binary package from this
+source without upgrading the others is not something that its upstream
+developers are ever going to test or support, and neither should we.
+(Closes: #969537)
+
+ -- Simon McVittie Mon, 15 Feb 2021 11:44:22 +
+
poppler (20.09.0-3.1) unstable; urgency=medium
* debian/tests: make autopkgtests cross-test-friendly (Closes: #969726)
diff --git a/debian/shlibs.local b/debian/shlibs.local
new file mode 100644
index 000..af3275a
--- /dev/null
+++ b/debian/shlibs.local
@@ -0,0 +1,4 @@
+libpoppler 102 libpoppler102 (= ${binary:Version})
+libpoppler-cpp 0 libpoppler-cpp0v5 (= ${binary:Version})
+libpoppler-glib 8 libpoppler-glib8 (= ${binary:Version})
+libpoppler-qt5 1 libpoppler-qt5-1 (= ${binary:Version})
--
2.30.0
