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: > > > Hi Jay, > > > > > > 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? > > > > Oh, you're right -- I didn't catch that. I haven't touched that aspect of > > the qpdf build in years, so I'm not sure how it got in there to begin with. > > I'll have to scrutinize this. > > > > > qpdf/libqpdf.map.in still seems to broad so that I think this > > > still needs some work upstream first to only apply the symbol version to > > > the actual symbols from libqpdf. > > > > 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? I'll have to get to the > > bottom of why non-QPDF symbols are sneaking in there with the symbol > > version. Regarding the breadth of the map, that was set up ages ago, > > and at the time, the advice I was given by the release team was to do > > something broad like that because trying to deal with real symbols > > with C++ name mangling is very complex. That said, I can automate it > > in some way. (I am upstream also BTW.) > > 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. I'll report back soon either way. Thanks! > Cheers > -- > Sebastian Ramacher >
