On 2026-08-11 13:56:48 -0400, Jay Berkenbilt wrote: > > > 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.
Could you check whether libqpdf30 in stable exported the std:: symbols with @LIBQPDF_30? Thanks Cheers -- Sebastian Ramacher
