* Jay Berkenbilt <[email protected]> [260811 17:26]:
On Tue, Aug 11, 2026, at 11:03 AM, Sebastian Ramacher wrote:
On 2026-08-11 10:48:05 -0400, Jay Berkenbilt wrote:
> On Tue, Aug 11, 2026, at 10:32 AM, Sebastian Ramacher wrote:
> > On 2026-08-11 16:01:02 +0200, Chris Hofstaedtler wrote:
> > > I'm not the expert, but the libcupsfilter log says:
> > > https://ci.debian.net/packages/libc/libcupsfilters/testing/arm64/74208469/
> > > /usr/bin/aarch64-linux-gnu-ld.bfd:
/usr/lib/gcc/aarch64-linux-gnu/15/../../../aarch64-linux-gnu/libcupsfilters.so:
> > > undefined reference to `std::__cxx11::basic_string<char,
> > > std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long,
> > > unsigned long, char const*, unsigned long)@LIBQPDF_30'
> >
> > These symbols should have never existed in the first place. These are
> > symbols from template instantiations of the standard library that
> > shouldn't have gained a LIBQPDF_30 symbol version. Did upstream clean up
> > their build system to no longer export those symbols with that symbol
> > version?
[..]
> Right. I don't want to do a major version bump...this isn't really an
> ABI change to qpdf though it is an ABI change to the debian packaged
> qpdf library binary. I'll either have to change the soname in the
> debian package until my next version bump using a suffix or something
> or else, well, I'm not sure actually. I guess in the meantime, I
> should revert by uploading a 12.4.0.1~really-12.3.2 or something. It's
> been years since I've had anything other than a completely routine
> upload. Is this a sensible approach for now?
[..]
We also had changes in the toolchain since the upload of 12.3.2-1. If
this aspect did not change in qpdf, this could also be change in the
toolchain. So before suggesting any actions, I would like to understand
where it is coming from. A rebuild of 12.3.2 may suffer the same issue.
It may be a couple of days before I can dig into this, but I'll try to
find time as soon as possible. I have automation in CI for qpdf that
dumps the symbols and compares so that accidental ABI breakage is
supposed to be impossible. I may filter on standard library, so I may
have shot myself in the foot. I will be able to tell for sure though
whether a local build of 12.3.2 and 12.4.0 on the same system behave
correctly with respect to exported symbols. Right now, if I determine
that I have accidentally done something to make this get tagged and it
disappeared, I'll do something to make it reappear and fix it for real
with qpdf 13.0.0. If it turns out to be a debian toolchain issue, I'll
stand by. I'll reply to this bug report when I have some information,
and if I determine that it's my mistake and I can fix it, then I'll
upload a fix and close the bugs in the changelog.
Indeed rebuilding qpdf 12.3.2-1 in unstable causes _M_replace and
other (weak) symbols to disappear from @LIBQPDF_30.
Best,
Chris
