Check-Script: shared-libs Author: Christian Schwarz Abbrev: shl Type: binary, udeb Unpack-Level: 2 Needs-Info: file-info, objdump-info Info: This script checks if a binary package conforms to shared library policy. Tag: shlib-with-executable-bit Severity: important Certainty: certain Info: Shared libraries should be mode 0644. Ref: policy 8.1 Tag: shlib-with-bad-permissions Severity: normal Certainty: certain Info: Shared libraries should be mode 0644. Ref: policy 8.1 Tag: shlib-with-non-pic-code Severity: serious Certainty: possible Ref: policy 10.2 Info: The listed shared libraries contain object code that was compiled without -fPIC. All object code in shared libraries should be recompiled separately from the static libraries with the -fPIC option. . Another common mistake that causes this problem is linking with gcc -Wl,-shared instead of gcc -shared. . In some cases, exceptions to this rule are warranted. If this is such a case, follow the procedure outlined in Policy and then please document the exception by adding a lintian override to this package. . To check whether a shared library has this problem, run readelf -d on the shared library. If a tag of type TEXTREL is present, the shared library contains non-PIC code. Tag: shlib-without-versioned-soname Severity: normal Certainty: possible Ref: policy 10.2, policy 8.6 Info: The listed shared library in a public library directory has an SONAME that does not contain any versioning information, either after the .so or before it and set off by a hyphen. It cannot therefore be represented in the shlibs system, and if linked by binaries its interface cannot safely change. There is no backward-compatible way to migrate programs linked against it to a new ABI. . Normally, this means the shared library is a private library for a particular application and is not meant for general use. Policy recommends that such libraries be installed in a subdirectory of /usr/lib rather than in a public shared library directory. . To view the SONAME of a shared library, run readelf -d on the shared library and look for the tag of type SONAME. . There are some special stub libraries or special-purpose shared objects for which an ABI version is not meaningful. If this is one of those cases, please add an override. Tag: ldconfig-symlink-missing-for-shlib Severity: important Certainty: certain Info: The package should not only include the shared library itself, but also the symbolic link which ldconfig would produce. (This is necessary, so that the link gets removed by dpkg automatically when the package gets removed.) If the symlink is in the package, check that the SONAME of the library matches the info in the shlibs file. Ref: policy 8.1 Tag: ldconfig-symlink-before-shlib-in-deb Severity: important Certainty: certain Info: In the package contents list, the shared library has to come before any symbolic links referencing the shared library. Ref: policy 8.1 Tag: dev-pkg-without-shlib-symlink Severity: normal Certainty: certain Info: A "-dev" package is supposed to install a "libsomething.so" symbolic link referencing the corresponding shared library. Notice how the link name doesn't include the version number -- this is because such a link is used by the linker when other programs are built against this shared library. Ref: policy 8.4 Tag: non-dev-pkg-with-shlib-symlink Severity: normal Certainty: possible Info: Although this package is not a "-dev" package, it installs a "libsomething.so" symbolic link referencing the corresponding shared library. When the link doesn't include the version number, it is used by the linker when other programs are built against this shared library. . Shared libraries are supposed to place such symbolic links in their respective "-dev" packages, so it is a bug to include it with the main library package. . However, if this is a small package which includes the runtime and the development libraries, this is not a bug. In the latter case, please override this warning. Ref: policy 8.4 Tag: preinst-calls-ldconfig Severity: normal Certainty: certain Info: The preinst script calls ldconfig. Calls to ldconfig should only be in postinst and postrm scripts. Ref: policy 8.1.1 Tag: prerm-calls-ldconfig Severity: normal Certainty: certain Info: The prerm script calls ldconfig. Calls to ldconfig should only be in postinst and postrm scripts. Ref: policy 8.1.1 Tag: postrm-unsafe-ldconfig Severity: normal Certainty: certain Info: The postrm script calls ldconfig unsafely. The postrm must only call ldconfig when given the argument "remove". Ref: policy 8.1.1 Tag: no-shlibs-control-file Severity: serious Certainty: possible Info: Although the package includes a shared library, the package does not have a shlibs control file. If this is intentional, please override this error. Ref: policy 8.6 Tag: pkg-has-shlibs-control-file-but-no-actual-shared-libs Severity: important Certainty: certain Info: Although the package does not include any shared libraries, it does have a shlibs control file. If you did include a shared library, check that the SONAME of the library is set and that it matches the contents of the shlibs file. . SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this. Tag: duplicate-entry-in-shlibs-control-file Severity: important Certainty: certain Info: The shlibs control file contains a duplicate entry. Tag: shlib-missing-in-control-file Severity: important Certainty: possible Info: The package contains a shared library that is not listed in the shlibs control file. If this is intentional, please override this error. Ref: policy 8.6 Tag: unused-shlib-entry-in-control-file Severity: normal Certainty: certain Info: The shlibs control file contains an entry for a shared library that is not installed by this package. Ref: policy 8.6 Tag: shlibs-declares-dependency-on-other-package Severity: normal Certainty: possible Info: This package declares in its shlibs control file either a dependency on some other package not listed in the Provides of this package or on a version of this package that the package version doesn't satisfy. . Packages should normally only list in their shlibs control file the shared libraries included in that package, and therefore the dependencies listed there should normally be satisfied by either the package itself or one of its Provides. . In unusual circumstances where it's necessary to declare more complex dependencies in the shlibs control file, please add a lintian override for this warning. Ref: policy 8.6 Tag: ldconfig-symlink-referencing-wrong-file Severity: important Certainty: certain Info: The symbolic link references the wrong file. (It should reference the shared library.) Ref: policy 8.1 Tag: ldconfig-symlink-is-not-a-symlink Severity: important Certainty: certain Info: The package installs a file with the name, ldconfig would use for the symbolic link to reference the shared library. Ref: policy 8.1 Tag: postinst-has-useless-call-to-ldconfig Severity: minor Certainty: certain Info: The postinst script calls ldconfig even though no shared libraries are installed in a directory controlled by the dynamic library loader. Ref: policy 8.1.1 Tag: udeb-postinst-must-not-call-ldconfig Severity: important Certainty: certain Info: The postinst script calls ldconfig, which is an error in udebs. ldconfig is not available and not needed in debian-installer Tag: postrm-has-useless-call-to-ldconfig Severity: minor Certainty: certain Info: The postrm script calls ldconfig even though no shared libraries are installed in a directory controlled by the dynamic library loader. Ref: policy 8.1.1 Tag: postinst-must-call-ldconfig Severity: serious Certainty: certain Info: The package installs shared libraries in a directory controlled by the dynamic library loader. Therefore, the package must call "ldconfig" in its postinst script. Ref: policy 8.1.1 Tag: postrm-should-call-ldconfig Severity: important Certainty: certain Info: The package installs shared libraries in a directory controlled by the dynamic library loader. Therefore, the package should call "ldconfig" in its postrm script. Ref: policy 8.1.1 Tag: sharedobject-in-library-directory-missing-soname Severity: important Certainty: possible Info: A shared object was identified in a library directory (a directory in the standard linker path) which doesn't have a SONAME. This is usually an error. . SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this. . To view the SONAME of a shared library, run readelf -d on the shared library and look for the tag of type SONAME. Tag: shlib-without-PT_GNU_STACK-section Severity: important Certainty: certain Info: The listed shared libraries lacks a PT_GNU_STACK section. This forces the dynamic linker to make the stack executable. . The shared lib is linked either with a non-GNU linker or a linker which is very old. This problem can be fixed with a rebuild. . To see whether a shared library has this section, run readelf -l on it and look for a program header of type GNU_STACK. Tag: shlib-with-executable-stack Severity: normal Certainty: possible Info: The listed shared libraries declares the stack as executable. . Executable stack is usually an error as it is only needed if the code contains GCC trampolines or similar constructs which uses code on the stack. One possible source for false positives are object files built from assembler files which don't define a proper .note.GNU-stack section. . To see the permissions on the stack, run readelf -l on the shared library and look for the program header of type GNU_STACK. In the flag column, there should not be an E flag set. Tag: symbols-file-contains-current-version-with-debian-revision Severity: important Certainty: certain Info: Debian revisions should be stripped from versions in symbols files. Not doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo << 1.0-1 while 1.0-1~bpo >= 1.0). If the debian revision can't be stripped because the symbol really appeared between two specific Debian revisions, you should postfix the version with a single "~" (example: 1.0-3~ if the symbol appeared in 1.0-3). . This problem normally means that the symbols were added automatically by dpkg-gensymbols. dpkg-gensymbols uses the full version number for the dependency associated to any new symbol that it detects. The maintainer must update the debian/<package>.symbols file by adding the new symbols with the corresponding upstream version. Tag: symbols-file-contains-debian-revision Severity: normal Certainty: certain Info: Debian revisions should be stripped from versions in symbols files. Not doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo << 1.0-1 while 1.0-1~bpo >= 1.0). If the debian revision can't be stripped because the symbol really appeared between two specific Debian revisions, you should postfix the version with a single "~" (example: 1.0-3~ if the symbol appeared in 1.0-3). Ref: dpkg-gensymbols(1), http://wiki.debian.org/UsingSymbolsFiles Tag: syntax-error-in-symbols-file Severity: important Certainty: certain Info: The symbols file contains an entry that does not follow the syntax rules for symbols files. . This may be due to the entry appearing out of sequence. Ref: deb-symbols(5) Tag: duplicate-entry-in-symbols-control-file Severity: important Certainty: certain Info: The symbols control file contains a duplicate entry. Tag: no-symbols-control-file Severity: wishlist Certainty: certain Info: Although the package includes a shared library, the package does not have a symbols control file. . dpkg can use symbols files in order to generate more accurate library dependencies for applications, based on the symbols from the library that are actually used by the application. Ref: dpkg-gensymbols(1), http://wiki.debian.org/UsingSymbolsFiles Tag: pkg-has-symbols-control-file-but-no-shared-libs Severity: important Certainty: certain Info: Although the package does not include any shared libraries, it does have a symbols control file. If you did include a shared library, check that the SONAME of the library is set and that it matches the contents of the symbols file. . SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this. Tag: shlib-missing-in-symbols-control-file Severity: normal Certainty: possible Info: The package contains a shared library that is not listed in the symbols control file. This may not be a problem if, for example, the library is a C++ library. Tag: unused-shlib-entry-in-symbols-control-file Severity: normal Certainty: certain Info: The symbols control file contains an entry for a shared library that is not installed by this package. Tag: symbols-declares-dependency-on-other-package Severity: normal Certainty: possible Info: This package declares in its symbols control file a dependency on some other package (and not one listed in the Provides of this package). . Packages should normally only list in their symbols control file the shared libraries included in that package, and therefore the dependencies listed there should normally be satisfied by either the package itself or one of its Provides. . In unusual circumstances where it's necessary to declare more complex dependencies in the symbols control file, please add a lintian override for this warning. Ref: policy 8.6 Tag: invalid-template-id-in-symbols-file Severity: important Certainty: certain Info: The symbol definition refers to an alternative dependency template which is not defined for the library containing the symbol. . The first alternative dependency template for a library the id number of 1, with the ids of subsequent alternative templates increasing in sequence. Tag: unknown-meta-field-in-symbols-file Severity: important Certainty: certain Info: The symbols control file contains an unknown meta-information field. . A list of currently supported fields may be found in deb-control(5). Ref: deb-control(5) Tag: symbols-declared-but-not-shlib Severity: important Certainty: certain Info: The symbols control file contains dependency and symbol information for a shared library which is not listed in the shlibs control file. Tag: shlib-calls-exit Severity: wishlist Certainty: possible Experimental: yes Info: The listed shared library calls the C library exit() or _exit() functions. . In the case of an error, the library should instead return an appropriate error code to the calling program which can then determine how to handle the error, including performing any required clean-up. . In most cases, removing the call should be discussed with upstream, particularly as it may produce an ABI change. Tag: incorrect-libdir-in-la-file Severity: important Certainty: possible Info: The given .la file points to a libdir other than the path where it is installed. This can be caused by resetting prefix at make install time instead of using DESTDIR. The incorrect path will cause packages linking to this library using libtool to build incorrectly (adding incorrect paths to RPATH, for example).