On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote: > - <sect id="sharedlibs-runtime"> > - <heading>Run-time shared libraries</heading> > + <p> > + A shared library must be uniquely identified by an <tt>SONAME</tt> > + attribute stored in its dynamic section. This wording is going to cause problems down the line. $ objdump -p /lib/libc.so.6 /lib/i686/cmov/libc.so.6 |grep SONAME SONAME libc.so.6 SONAME libc.so.6 $ $ objdump -p /lib/libc.so.6 /lib32/libc.so.6 |grep SONAME SONAME libc.so.6 SONAME libc.so.6 $ And multiarch further increases the frequency of non-unique SONAMEs on the system. So more explanation is needed of what 'unique' actually means here. > When a binary is linked > + against a shared library, the <tt>SONAME</tt> of the shared > + library is recorded in the binary's <tt>NEEDED</tt> section so > + that the dynamic linker knows that library must be loaded at > + runtime. The full name of the shared library (which usually I would say "the shared library's full file name", as I consider the SONAME to *be* the name of the library :) > + contains additional version information not needed in > + the <tt>SONAME</tt> is therefore not referenced directly. > + Instead, the shared library is loaded by its <tt>SONAME</tt>, > + which exists on the file system as a symlink pointing to the full > + name of the shared library.<footnote> > + Some unusual libraries have an <tt>SONAME</tt> which matches the > + full library name, but normally there is a minor revision that > + changes even though the ABI has not changed in a > + backward-incompatible way. The <tt>SONAME</tt> only changes > + when binaries linked with the earlier version of the shared > + library may no longer work. See <ref id="sharedlibs-runtime"> > + for more information. > + </footnote> I would write this footnote as: This is a convention of shared library versioning, but not a requirement. Some libraries use the <tt>SONAME</tt> as the full library file name instead. Most, however, encode additional information about backwards-compatible revisions as a minor version number in the file name. The <tt>SONAME</tt> itself only changes when binaries linked with the earlier version of the shared library may no longer work, but the filename may change with each release of the library. See <ref id="sharedlibs-runtime"> for more information. > + When linking a binary or another shared library against a shared > + library, the <tt>SONAME</tt> for that shared library is not yet > + known. Instead, the shared library is found by library name > + with <tt>.so</tt> appended. This file exists on the file system > + as a symlink pointing to the shared library.<footnote> > + Some shared libraries have no version information in > + their <tt>SONAME</tt> and therefore need no symlink since the > + file found when linking is the same as the library name. This > + is highly unusual, however, and means the shared library cannot > + be versioned. It is used only for very special situations where > + the shared library provides a tiny set of symbols and must not > + be versioned for some reason. > + </footnote> I don't think this footnote adds anything. Why document that it's possible to create shared libraries that don't follow policy? > - <p> > - Since it is common place to install several versions of a > - package that just provides shared libraries, it is a > - good idea that the library package should not > - contain any extraneous non-versioned files, unless they > - happen to be in versioned directories.</p> I don't see anywhere else that this recommendation is retained in this patch. The existing wording is rough, but I think it needs to be pointed out that shared lib packages can't contain other files in unversioned paths without running into Breaks/Replaces pain. > + > + <p> > - If you have several shared libraries built from the same > - source tree you may lump them all together into a single > - shared library package, provided that you change all of > - their sonames at once (so that you don't get filename > - clashes if you try to install different versions of the > - combined shared libraries package). > + If you have several shared libraries built from the same source > + tree, you may lump them all together into a single shared > + library package provided that all of their <tt>SONAME</tt>s will > + always change together. Be aware that this is not normally the > + case, and if the <tt>SONAME</tt>s do not change together, > + upgrading such a merged shared library package will be > + unnecessarily difficult because of file conflicts with the old > + version of the package. When in doubt, always split shared > + library packages so that each binary package installs a single > + shared library. > + </p> Thanks, definite improvement in wording. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature