Bug#896012: lintian: Remove tag library-not-linked-against-libc

[Felix Lechner]

P.S: A recent archive-wide run showed 334 overrides and 
occurrences. The override ratio does not support a removal, but the
total number of occurrences may. Could it be true that we are shipping
 defective shared libraries? I don't think so.

Also, the tag carries the Severity 'error'.

Kind regards
Felix Lechner

* * *

detagtive=> SELECT count(taxiv.hint.id) AS hints,
count(taxiv.override.id) AS overrides

FROM taxiv.hint

INNER JOIN taxiv.run ON taxiv.run.id = taxiv.hint.run_id
INNER JOIN ftp.source ON ftp.source.id = taxiv.run.ftp_source_id
INNER JOIN ftp.source_name ON ftp.source_name.id = ftp.source.source_name_id
INNER JOIN lintian.tag ON lintian.tag.id = taxiv.hint.lintian_tag_id
INNER JOIN lintian.tag_name ON lintian.tag_name.id = lintian.tag.tag_name_id
LEFT JOIN taxiv.override ON taxiv.override.hint_id = taxiv.hint.id

WHERE
taxiv.run.lintian_version_id = 3
AND
lintian.tag_name.literal = 'library-not-linked-against-libc'

 hints | overrides
---+---
   |   334
(1 row)

Bug#896012: lintian: Remove tag library-not-linked-against-libc

[Felix Lechner]

Control: retitle -1 lintian: Remove tag library-not-linked-against-libc

Hi,

> So probably we need an update for our QA tools to do a better detection of
> dynamically linked binaries.

Lintian cannot detect this tag reliably. It should probably be removed.

Like many other dependency-type problems in Debian, the analysis of
library prerequisites requires a tool with an archive-wide
perspective. The Lintian team may eventually be able to provide
something on lintian.d.o, but the stand-alone program 'lintian' cannot
do it.

In the case of fwupd, Lintian sees the following, immediate library
requirements:

% readelf -WltdVs
dir/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_recovery.so
...
 0x0001 (NEEDED) Shared library: [libfwupd.so.2]
 0x0001 (NEEDED) Shared library: [libfwupdplugin.so.1]
 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0]
 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0]
...

while ldd resolves the whole tree:

% ldd dir/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi_recovery.so
linux-vdso.so.1 (0x7ffd7ebca000)
libfwupd.so.2 => /lib/x86_64-linux-gnu/libfwupd.so.2 (0x7fea01bce000)
libfwupdplugin.so.1 => not found
libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0
(0x7fea01b79000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7fea01a5a000)
libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x7fea0189c000)
libsoup-2.4.so.1 => /lib/x86_64-linux-gnu/libsoup-2.4.so.1
(0x7fea0180c000)
libjson-glib-1.0.so.0 =>
/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 (0x7fea017e)
*   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fea0161f000)
libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x7fea01615000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fea015f4000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fea0158)
libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0
(0x7fea0157a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fea0135a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fea01355000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x7fea012f6000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x7fea010ce000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fea010b4000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2
(0x7fea01067000)
libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x7fea00ebc000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7fea00d9a000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7fea00d87000)
/lib64/ld-linux-x86-64.so.2 (0x7fea01c1d000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7fea00d32000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fea00d28000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7fea00c46000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3
(0x7fea00c12000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
(0x7fea00c0c000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0
(0x7fea00bfd000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
(0x7fea00bf6000)
libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63
(0x7fea0091b000)
libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 (0x7fea0074a000)
libicudata.so.63 => /lib/x86_64-linux-gnu/libicudata.so.63
(0x7fe9fed5a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fe9fed32000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe9febaf000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7fe9feb9)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2
(0x7fe9fea0c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fe9fea01000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fe9fe87d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fe9fe863000)

As one can see, the dynamic linker makes libc.so.6 available
indirectly, but that analysis is possible only on a running system.
Another approach would be to scan all shared libraries in the archive
and construct the dependency tree. Both are outside Lintian's purview.

The bootstrapping folks occasionally approach the Lintian team with
requests for similar analysis. Their solution will also require a
portfolio-type approach, and a new tool. Let's call it
'detaxification' for now. It resolves dependencies.

> lintian generates false positives for library-not-linked-against-libc after 
> gcc-7 7.3.0-16

Perhaps the previous title of the bug report is valuable for posterity.

Kind regards
Felix Lechner