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