[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#696259: marked as done (Discourage (preferably forbid) underlinked public shared libraries)



Your message dated Tue, 18 Dec 2012 19:45:24 +0000
with message-id <20121218194524.GA31294@wrar.name>
and subject line Re: Bug#696259: Discourage (preferably forbid) underlinked public shared libraries
has caused the Debian Bug report #696259,
regarding Discourage (preferably forbid) underlinked public shared libraries
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
696259: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696259
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Severity: wishlist

Hereinafter "libraries" means "public shared libraries" per Policy §8 and only
them.

I couldn't find in the Policy anything about underlinked libraries while I
believe that having them is wrong and should be considered a bug.

I mean libraries that are not directly linked against all libraries whose
symbols are used. In the worst case this manifests as "undefined reference"
lines in the ldd -r output and means that you must satisfy these references by
linking additional libraries to the binaries that use the underlinked library
(by linking against it or dlopening it). If you don't do this, sometimes you
may not notice the problem until you invoke a specific code path that uses
these references. Formally this also means that packages using the underlinked
library may have RC bugs that can't be fixed, only worked around by linking
additional libraries (cf. #694846 caused by #677721).

In some cases a library doesn't have undefined symbols because of indirect
dependencies but that's just a hidden bug and it can appear at any time when
indirect deps change. In this case ldd won't show undefined references but
automatic detection of the problem should still be possible.

Also, if a library is underlinked we cannot use the dpkg dependencies to
document the library dependencies. Also, underlinking of a library causes
overlinking for binaries that use it and that is a problem by itself.

See also http://wiki.mandriva.com/en/Underlinking


So, I propose adding something like "Shared libraries should be linked against
all libraries they use directly" to §8.1.



-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.7.0-wrar-1+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message ---
On Tue, Dec 18, 2012 at 09:51:19AM -0800, Steve Langasek wrote:
> Policy 10.2:
> 
>      Although not enforced by the build tools, shared libraries must be
>      linked against all libraries that they use symbols from in the same
>      way that binaries are.  This ensures the correct functioning of the
>      symbols and shlibs systems and guarantees that all libraries can be
>      safely opened with `dlopen()'.  Packagers may wish to use the gcc
>      option `-Wl,-z,defs' when building a shared library.  Since this
>      option enforces symbol resolution at build time, a missing library
>      reference will be caught early as a fatal build error.
Oh, sorry for the noise.

--- End Message ---

Reply to: