Package: libcairo-gobject-perl Version: 1.004-3 Severity: important I've spotted this error while packaging 1.005:
E: libcairo-gobject-perl: library-not-linked-against-libc usr/lib/x86_64-linux-gnu/perl5/5.28/auto/Cairo/GObject/GObject.so N: N: The package installs a library which is not dynamically linked against N: libc. N: N: It is theoretically possible to have a library which doesn't use any N: symbols from libc, but it is far more likely that this is a violation of N: the requirement that "shared libraries must be linked against all N: libraries that they use symbols from in the same way that binaries are". N: N: Refer to Debian Policy Manual section 10.2 (Libraries) and N: https://bugs.debian.org/698720 for details. N: N: Severity: important, Certainty: possible N: N: Check: binaries, Type: binary, udeb If I rebuild 1.004-3 I see the same problem so it's caused by a change in build-dependencies, and not by the new libcairo-gobject-perl upstream release. I've investigated a bit with this command: objdump -Tx /usr/lib/x86_64-linux-gnu/perl5/5.*/auto/Cairo/GObject/GObject.so 1. 1.004-3+b1 that's in the archive (binNMU from 2018-11-02) - there's a "NEEDED" for libc.so.6 - the "DYNAMIC SYMBOL TABLE" section includes: 0000000000000000 w DF *UND* 0000000000000000 GLIBC_2.2.5 __cxa_finalize 2. Fresh build of 1.005-1 - no "NEEDED" for libc.so.6, hence the Lintian error - __cxa_finalize is still present in the dynamic symbol table So this does not look like a false positive: at least one symbol from libc is directly used by the library, so presumably it should be linked against libc. In both cases, all other symbols listed in the dynamic symbol table section have names that suggest they're coming from perl, GLib, or Cairo libraries. I'm not blocking on this to upload 1.005-1 because this could happen just as well with a binNMU next week (random example: as part of the perl 5.30 transition), regardless of whether I upload or not. And it seems to be a minor problem here: the only libc symbol that's used directly by this .so file was introduced in libc6 2.2.5, which was uploaded to sid in 2002; I doubt this will ever change given the nature of this library and its build system. However, I don't dare adding a Lintian override: I'm not well versed in the shared library / linker space and might very well be underestimating the severity of this problem. For whoever, better skilled at this than me, will investigate this problem: - #909267 might be interesting - I don't know if -Wl,--as-needed is passed during the build: the actual call to the linker is obfuscated as "LD". Cheers, -- intrigeri
