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:
w DF *UND* 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
