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. Cheers -- Sebastian Ramacher
