</p>
<p>
- Thus, when a package is built which contains any shared
- libraries, it must provide a <file>shlibs</file> 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 <file>shlibs</file> file for other packages to
+ use. When a package is built which contains any shared
+ libraries or compiled binaries, it must run
<qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref>
on these to determine the libraries used and hence the
dependencies needed by this package.<footnote>
<p>
- In the past, the shared libraries linked to were
- determined by calling <prgn>ldd</prgn>, but now
- <prgn>objdump</prgn> is used to do this. The only
- change this makes to package building is that
- <prgn>dpkg-shlibdeps</prgn> 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.
+ <prgn>dpkg-shlibdeps</prgn> will use a program
+ like <prgn>objdump</prgn> or <prgn>readelf</prgn> to find
+ the libraries directly needed by the binaries or shared
+ libraries in the package.
</p>
<p>
We say that a binary <tt>foo</tt> <em>directly</em> uses
a library <tt>libbar</tt> if it is explicitly linked
- with that library (that is, it uses the flag
- <tt>-lbar</tt> during the linking stage). Other
+ with that library (that is, the library is listed in the ELF
+ <tt>NEEDED</tt> attribute, caused by adding <tt>-lbar</tt>
+ to the link line when the binary is created). Other
libraries that are needed by <tt>libbar</tt> are linked
<em>indirectly</em> to <tt>foo</tt>, and the dynamic
linker will load them automatically when it loads
- <tt>libbar</tt>. A package should depend on
- the libraries it directly uses, and the dependencies for
- those libraries should automatically pull in the other
- libraries.
- </p>
-
- <p>
- Unfortunately, the <prgn>ldd</prgn> program shows both
- the directly and indirectly used libraries, meaning that
- the dependencies determined included both direct and
- indirect dependencies. The use of <prgn>objdump</prgn>
- avoids this problem by determining only the directly
- used libraries.
+ <tt>libbar</tt>. 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.
</p>
<p>
A good example of where this helps is the following. We
could update <tt>libimlib</tt> with a new version that
- supports a new graphics format called dgf (but retaining
- the same major version number). If we used the old
- <prgn>ldd</prgn> method, every package that uses
- <tt>libimlib</tt> would need to be recompiled so it
- would also depend on <tt>libdgf</tt> or it wouldn't run
- due to missing symbols. However with the new system,
- packages using <tt>libimlib</tt> can rely on
- <tt>libimlib</tt> itself having the dependency on
- <tt>libdgf</tt> and so they would not need rebuilding.
+ supports a new graphics format called dgf (but retaining the
+ same major version number) and depends on <tt>libdgf</tt>.
+ If we used <prgn>ldd</prgn> to add dependencies for every
+ library directly or indirectly linked with a binary, every
+ package that uses <tt>libimlib</tt> would need to be
+ recompiled so it would also depend on <tt>libdgf</tt> or it
+ wouldn't run due to missing symbols. Since dependencies are
+ only added based on ELF <tt>NEEDED</tt> attribute, packages
+ using <tt>libimlib</tt> can rely on <tt>libimlib</tt> itself
+ having the dependency on <tt>libdgf</tt> and so they would
+ not need rebuilding.
</p>
</footnote>
</p>
<p><file>DEBIAN/shlibs</file> files in the "build directory"</p>
<p>
- When packages are being built, any
- <file>debian/shlibs</file> files are copied into the
+ When packages are being built,
+ any <file>debian/shlibs</file> files are copied into the
control file area of the temporary build directory and
given the name <file>shlibs</file>. These files give
- details of any shared libraries included in the
+ details of any shared libraries included in the same
package.<footnote>
- An example may help here. Let us say that the
- source package <tt>foo</tt> generates two binary
- packages, <tt>libfoo2</tt> and
- <tt>foo-runtime</tt>. When building the binary
- packages, the two packages are created in the
- directories <file>debian/libfoo2</file> and
- <file>debian/foo-runtime</file> respectively.
- (<file>debian/tmp</file> could be used instead of one
- of these.) Since <tt>libfoo2</tt> provides the
- <tt>libfoo</tt> shared library, it will require a
- <tt>shlibs</tt> file, which will be installed in
- <file>debian/libfoo2/DEBIAN/shlibs</file>, eventually
- to become
- <file>/var/lib/dpkg/info/libfoo2.shlibs</file>. Then
- when <prgn>dpkg-shlibdeps</prgn> is run on the
- executable
- <file>debian/foo-runtime/usr/bin/foo-prog</file>, it
- will examine the
- <file>debian/libfoo2/DEBIAN/shlibs</file> file to
- determine whether <tt>foo-prog</tt>'s library
- dependencies are satisfied by any of the libraries
- provided by <tt>libfoo2</tt>. For this reason,
- <prgn>dpkg-shlibdeps</prgn> must only be run once
- all of the individual binary packages'
- <tt>shlibs</tt> files have been installed into the
- build directory.
+ An example may help here. Let us say that the source
+ package <tt>foo</tt> generates two binary
+ packages, <tt>libfoo2</tt> and <tt>foo-runtime</tt>.
+ When building the binary packages, the two packages are
+ created in the directories <file>debian/libfoo2</file>
+ and <file>debian/foo-runtime</file> respectively.
+ (<file>debian/tmp</file> could be used instead of one of
+ these.) Since <tt>libfoo2</tt> provides the
+ <tt>libfoo</tt> shared library, it will require a
+ <tt>shlibs</tt> file, which will be installed in
+ <file>debian/libfoo2/DEBIAN/shlibs</file>, eventually to
+ become <file>/var/lib/dpkg/info/libfoo2.shlibs</file>.
+ When <prgn>dpkg-shlibdeps</prgn> is run on the
+ executable <file>debian/foo-runtime/usr/bin/foo-prog</file>,
+ it will examine
+ the <file>debian/libfoo2/DEBIAN/shlibs</file> file to
+ determine whether <tt>foo-prog</tt>'s library
+ dependencies are satisfied by any of the libraries
+ provided by <tt>libfoo2</tt>. For this reason,
+ <prgn>dpkg-shlibdeps</prgn> must only be run once all of
+ the individual binary packages' <tt>shlibs</tt> files
+ have been installed into the build directory.
</footnote>
</p>
</item>
</example>
Otherwise, you will need to explicitly list the compiled
binaries and libraries.<footnote>
- If you are using <tt>debhelper</tt>, the
- <prgn>dh_shlibdeps</prgn> program will do this work for
- you. It will also correctly handle multi-binary
- packages.
+ If you are using <tt>debhelper</tt>, the
+ <prgn>dh_shlibdeps</prgn> program will do this work for you.
+ It will also correctly handle multi-binary packages.
</footnote>
</p>
you will need to specify that <prgn>dpkg-shlibdeps</prgn>
should use the dependency line of type <tt>udeb</tt> by
adding the <tt>-tudeb</tt> option<footnote>
- <prgn>dh_shlibdeps</prgn> from the <tt>debhelper</tt> suite
- will automatically add this option if it knows it is
- processing a udeb.
- </footnote>. If there is no dependency line of type <tt>udeb</tt>
- in the <file>shlibs</file> file, <prgn>dpkg-shlibdeps</prgn> will
- fall back to the regular dependency line.
+ <prgn>dh_shlibdeps</prgn> from the <tt>debhelper</tt> suite
+ will automatically add this option if it knows it is
+ processing a udeb.
+ </footnote>. If there is no dependency line of
+ type <tt>udeb</tt> in the <file>shlibs</file>
+ file, <prgn>dpkg-shlibdeps</prgn> will fall back to the regular
+ dependency line.
</p>
<p>
- For more details on dpkg-shlibdeps, please see
+ For more details on <prgn>dpkg-shlibdeps</prgn>, please see
<ref id="pkg-dpkg-shlibdeps"> and
<manref name="dpkg-shlibdeps" section="1">.
</p>
usually of the form
<tt><var>name</var>.so.<var>major-version</var></tt>, in our
example, <tt>libz.so.1</tt>.<footnote>
- This can be determined using the command
- <example compact="compact">
+ This can be determined using the command
+ <example compact="compact">
objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
- </example>
+ </example>
</footnote>
The version part is the part which comes after
<tt>.so.</tt>, so in our case, it is <tt>1</tt>.
<file>shlibs</file> file in the control area directly from
<file>debian/rules</file> without using a <file>debian/shlibs</file>
file at all,<footnote>
- This is what <prgn>dh_makeshlibs</prgn> in the
- <tt>debhelper</tt> suite does. If your package also has a udeb
- that provides a shared library, <prgn>dh_makeshlibs</prgn> can
- automatically generate the <tt>udeb:</tt> lines if you specify
- the name of the udeb with the <tt>--add-udeb</tt> option.
+ This is what <prgn>dh_makeshlibs</prgn> in
+ the <package>debhelper</package> suite does. If your package
+ also has a udeb that provides a shared
+ library, <prgn>dh_makeshlibs</prgn> can automatically generate
+ the <tt>udeb:</tt> lines if you specify the name of the udeb
+ with the <tt>--add-udeb</tt> option.
</footnote>
since the <file>debian/shlibs</file> file itself is ignored by
<prgn>dpkg-shlibdeps</prgn>.
projects / debian / debian-policy.git / commitdiff