On Mon, 25 Jan 2021 23:20:37 +0100, Sebastian Andrzej Siewior <sebast...@breakpoint.cc> wrote: > On 2021-01-25 22:59:08 [+0100], Stephen Kitt wrote: > > That was no doubt the intention, however in practice the symbol > > visibility wasn’t as expected: looking at the .so build in version > > 1.3.8, common/pool.c includes common/zstd_internal.h which defines > > ZSTD_STATIC_LINKING_ONLY before including zstd.h, and as a result the > > symbols are visible. > > > > (It’s unfortunate that the build hides the exact commands used, so > > they’re not visible in the build logs, but that’s another issue. Easy > > enough to fix in a local build to see exactly what’s going on...) > > > > So the cat is out of the bag, and the symbols are present and visible > > in the .so. The symbols file is generated and only reflects the > > reality of what is present in the file (apart from the version numbers > > which are added manually). > > I opened the bug because I couldn't use these symbols in Buster's zstd > but had to use bpo instead. rsync is meanwhile available in bpo and > pulls-in the libzstd from bpo which is good. > > I have no idea what should be done here to close this properly.
I think the best fix at this point will be to bump the versions in the symbols file to match the intention, and then binNMU all the packages with a dependency on (>= 1.3.8) so that they get fixed to (>= 1.4.0) if appropriate. I haven’t finished looking into the current upstream situation in detail but it seems this is fixed, so we shouldn’t run into the issue for later symbols. I’ll NMU zstd (unless anyone from the med team objects) and send a summary to the release team. Regards, Stephen
pgpfQI4nxZKR0.pgp
Description: OpenPGP digital signature
