From be3ace38f418075b9776e957f3e31073cd015fba Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Thu, 1 Jul 2010 11:51:22 -0700 Subject: [PATCH] Reformat and update the shlibs section * Revise the footnote discussing shlibs creation to not talk about the switch to objdump as if it were a new innovation and to explicitly mention the NEEDED attribute as the source of dependency information. Also fix markup, formatting, indentation, and phrasing in multiple places. --- debian/changelog | 3 + policy.sgml | 155 ++++++++++++++++++++++------------------------- 2 files changed, 74 insertions(+), 84 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5ccc464..ae35d8c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -19,6 +19,9 @@ debian-policy (3.9.1.0) UNRELEASED; urgency=low allowed from main to contrib or non-free and mention that such relationships are okay if the non-free package is only an alternative. Thanks, Raphael Geissert. (Closes: #587279) + * Revise the footnote discussing shlibs creation to not talk about the + switch to objdump as if it were a new innovation and to explicitly + mention the NEEDED attribute as the source of dependency information. -- Russ Allbery Mon, 28 Jun 2010 09:34:54 -0700 diff --git a/policy.sgml b/policy.sgml index 2635fa8..1e641e6 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5398,59 +5398,49 @@ Replaces: mail-transport-agent

- Thus, when a package is built which contains any shared - libraries, it must provide a shlibs file for other - packages to use, and when a package is built which contains - any shared libraries or compiled binaries, it must run + When a package is built which contains any shared libraries, it + must provide a shlibs file for other packages to + use. When a package is built which contains any shared + libraries or compiled binaries, it must run dpkg-shlibdeps on these to determine the libraries used and hence the dependencies needed by this package.

- In the past, the shared libraries linked to were - determined by calling ldd, but now - objdump is used to do this. The only - change this makes to package building is that - dpkg-shlibdeps must also be run on shared - libraries, whereas in the past this was unnecessary. - The rest of this footnote explains the advantage that - this method gives. + dpkg-shlibdeps will use a program + like objdump or readelf to find + the libraries directly needed by the binaries or shared + libraries in the package.

We say that a binary foo directly uses a library libbar if it is explicitly linked - with that library (that is, it uses the flag - -lbar during the linking stage). Other + with that library (that is, the library is listed in the ELF + NEEDED attribute, caused by adding -lbar + to the link line when the binary is created). Other libraries that are needed by libbar are linked indirectly to foo, and the dynamic linker will load them automatically when it loads - libbar. A package should depend on - the libraries it directly uses, and the dependencies for - those libraries should automatically pull in the other - libraries. -

- -

- Unfortunately, the ldd program shows both - the directly and indirectly used libraries, meaning that - the dependencies determined included both direct and - indirect dependencies. The use of objdump - avoids this problem by determining only the directly - used libraries. + libbar. A package should depend on the libraries + it directly uses, but not the libraries it indirectly uses. + The dependencies for those libraries will automatically pull + in the other libraries.

A good example of where this helps is the following. We could update libimlib with a new version that - supports a new graphics format called dgf (but retaining - the same major version number). If we used the old - ldd method, every package that uses - libimlib would need to be recompiled so it - would also depend on libdgf or it wouldn't run - due to missing symbols. However with the new system, - packages using libimlib can rely on - libimlib itself having the dependency on - libdgf and so they would not need rebuilding. + supports a new graphics format called dgf (but retaining the + same major version number) and depends on libdgf. + If we used ldd to add dependencies for every + library directly or indirectly linked with a binary, every + package that uses libimlib would need to be + recompiled so it would also depend on libdgf or it + wouldn't run due to missing symbols. Since dependencies are + only added based on ELF NEEDED attribute, packages + using libimlib can rely on libimlib itself + having the dependency on libdgf and so they would + not need rebuilding.

@@ -5499,38 +5489,34 @@ Replaces: mail-transport-agent

DEBIAN/shlibs files in the "build directory"

- When packages are being built, any - debian/shlibs files are copied into the + When packages are being built, + any debian/shlibs files are copied into the control file area of the temporary build directory and given the name shlibs. These files give - details of any shared libraries included in the + details of any shared libraries included in the same package. - An example may help here. Let us say that the - source package foo generates two binary - packages, libfoo2 and - foo-runtime. When building the binary - packages, the two packages are created in the - directories debian/libfoo2 and - debian/foo-runtime respectively. - (debian/tmp could be used instead of one - of these.) Since libfoo2 provides the - libfoo shared library, it will require a - shlibs file, which will be installed in - debian/libfoo2/DEBIAN/shlibs, eventually - to become - /var/lib/dpkg/info/libfoo2.shlibs. Then - when dpkg-shlibdeps is run on the - executable - debian/foo-runtime/usr/bin/foo-prog, it - will examine the - debian/libfoo2/DEBIAN/shlibs file to - determine whether foo-prog's library - dependencies are satisfied by any of the libraries - provided by libfoo2. For this reason, - dpkg-shlibdeps must only be run once - all of the individual binary packages' - shlibs files have been installed into the - build directory. + An example may help here. Let us say that the source + package foo generates two binary + packages, libfoo2 and foo-runtime. + When building the binary packages, the two packages are + created in the directories debian/libfoo2 + and debian/foo-runtime respectively. + (debian/tmp could be used instead of one of + these.) Since libfoo2 provides the + libfoo shared library, it will require a + shlibs file, which will be installed in + debian/libfoo2/DEBIAN/shlibs, eventually to + become /var/lib/dpkg/info/libfoo2.shlibs. + When dpkg-shlibdeps is run on the + executable debian/foo-runtime/usr/bin/foo-prog, + it will examine + the debian/libfoo2/DEBIAN/shlibs file to + determine whether foo-prog's library + dependencies are satisfied by any of the libraries + provided by libfoo2. For this reason, + dpkg-shlibdeps must only be run once all of + the individual binary packages' shlibs files + have been installed into the build directory.

@@ -5576,10 +5562,9 @@ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ Otherwise, you will need to explicitly list the compiled binaries and libraries. - If you are using debhelper, the - dh_shlibdeps program will do this work for - you. It will also correctly handle multi-binary - packages. + If you are using debhelper, the + dh_shlibdeps program will do this work for you. + It will also correctly handle multi-binary packages.

@@ -5611,16 +5596,17 @@ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ you will need to specify that dpkg-shlibdeps should use the dependency line of type udeb by adding the -tudeb option - dh_shlibdeps from the debhelper suite - will automatically add this option if it knows it is - processing a udeb. - . If there is no dependency line of type udeb - in the shlibs file, dpkg-shlibdeps will - fall back to the regular dependency line. + dh_shlibdeps from the debhelper suite + will automatically add this option if it knows it is + processing a udeb. + . If there is no dependency line of + type udeb in the shlibs + file, dpkg-shlibdeps will fall back to the regular + dependency line.

- For more details on dpkg-shlibdeps, please see + For more details on dpkg-shlibdeps, please see and .

@@ -5664,10 +5650,10 @@ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ usually of the form name.so.major-version, in our example, libz.so.1. - This can be determined using the command - + This can be determined using the command + objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME - + The version part is the part which comes after .so., so in our case, it is 1. @@ -5724,11 +5710,12 @@ install -m644 debian/shlibs.package debian/package/DEBIAN/ shlibs file in the control area directly from debian/rules without using a debian/shlibs file at all, - This is what dh_makeshlibs in the - debhelper suite does. If your package also has a udeb - that provides a shared library, dh_makeshlibs can - automatically generate the udeb: lines if you specify - the name of the udeb with the --add-udeb option. + This is what dh_makeshlibs in + the debhelper suite does. If your package + also has a udeb that provides a shared + library, dh_makeshlibs can automatically generate + the udeb: lines if you specify the name of the udeb + with the --add-udeb option. since the debian/shlibs file itself is ignored by dpkg-shlibdeps. -- 2.39.5