On Tue, Aug 11, 2026, at 12:35 PM, Chris Hofstaedtler wrote: > * 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
So then this sounds like a toolchain issue on the debian side? Come to think of it, when I released 12.3.2, there was some churn on the toolchain, and I was unable to build in my local chroot -- binutils had been updated about four hours earlier. I waited a few days and tried again, and it was successful...but perhaps my previous upload was timed poorly, and I got stuck with a tooling issue. If I'm reading your response correctly, the solution would be to rebuild qpdf's downstream dependencies perhaps a rebuild 12.3.2 and then see if the 12.4.0 transition is able to go? Let me know if there's anything I need to do on my side. Thanks for the quick responses in looking into this issue. --Jay
