Bug#698720: lintian: consider {library,program}-not-linked-against-libc important & possible
Package: lintian
Version: 2.5.11
Severity: wishlist
Dear Maintainer,
I've prepared a patch to increase the severity, but decrease the
certainty, of library-not-linked-against-libc and
program-not-linked-against-libc, and to improve their descriptions.
I think program-not-linked-against-libc could still use some more meat,
possibly mentioning some of the following facts to explain why libc
should/must be NEEDED *directly*:
* that {,g,S}crt1.o -- from which GCC gets the executable entry point
"_start" for normal, profiling, and position-independant executables
(respectively, and only without -no-startfiles) -- all call
__libc_start_main()
* that libc.so is a linker script that pulls in libc_nonshared.a,
which is needed for stat() and friends and atexit() to be available
at all
* that it's needed for symbol versioning
* that it's needed for dpkg-shlibdeps to work properly
diff --git a/checks/binaries.desc b/checks/binaries.desc
index d24e045..a2da87d 100644
--- a/checks/binaries.desc
+++ b/checks/binaries.desc
@@ -41,16 +41,27 @@ Info: The package installs a statically linked binary or object file.
excluded, as are any binaries in packages named *-static.
Tag: library-not-linked-against-libc
-Severity: minor
-Certainty: certain
+Severity: important
+Certainty: possible
+Ref: policy 10.2
Info: The package installs a library which is not dynamically linked
against libc.
+ .
+ It is theoretically possible to have a library which doesn't use any
+ symbols from libc, but it is far more likely that this is a violation
+ of the requirement that "shared libraries must be linked against all
+ libraries that they use symbols from in the same way that binaries
+ are".
Tag: program-not-linked-against-libc
-Severity: minor
-Certainty: certain
+Severity: important
+Certainty: possible
Info: The package installs a binary which is not dynamically linked
against libc.
+ .
+ It is theoretically possible to have a program which doesn't use any
+ symbols from libc, but it is far more likely that this binary simply
+ isn't linked correctly.
Tag: binary-or-shlib-defines-rpath
Severity: serious
-- System Information:
Debian Release: 7.0
APT prefers testing-proposed-updates
APT policy: (991, 'testing-proposed-updates'), (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages lintian depends on:
ii binutils 2.22-7.1
ii bzip2 1.0.6-4
ii diffstat 1.55-3
ii file 5.11-2
ii gettext 0.18.1.1-9
ii hardening-includes 2.2
ii intltool-debian 0.35.0+20060710.1
ii libapt-pkg-perl 0.1.26+b1
ii libarchive-zip-perl 1.30-6
ii libc-bin 2.13-37
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.31-1+b2
ii libdigest-sha-perl 5.71-1
ii libdpkg-perl 1.16.9
ii libemail-valid-perl 0.190-1
ii libipc-run-perl 0.92-1
ii libparse-debianchangelog-perl 1.2.0-1
ii libtimedate-perl 1.2000-1
ii liburi-perl 1.60-1
ii man-db 2.6.2-1
ii patchutils 0.3.2-1.1
ii perl [libdigest-sha-perl] 5.14.2-16
lintian recommends no packages.
Versions of packages lintian suggests:
ii binutils-multiarch 2.22-7.1
ii dpkg-dev 1.16.9
ii libhtml-parser-perl 3.69-2
pn libperlio-gzip-perl <none>
ii libtext-template-perl 1.45-2
ii man-db 2.6.2-1
ii xz-utils [lzma] 5.1.1alpha+20120614-2
-- no debconf information
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Reply to: