Manoj Srivastava <srivasta@debian.org> writes:
> On Wed, 30 May 2007 18:28:43 +0200, Raphael Hertzog <hertzog@debian.org> said:
>> What Guillem said is that checklib also indicated binaries which are
>> linked against a library without using any of its symbols. Thus the
>> binary shouldn't have been linked against it in the first place. That
>> link has a cost in "load time" that can be avoided.
>>
>> checklib is still useful for this.
> Hmm. The instances I find for this is where a bunch of binaries
> are created from the same source; and upstream has been lazy enough to
> not create custom CFLAGS/LDFLAGS for each binary, just setting up a
> common build flag set for the whole package; in which case yes, some
> binaries are linked against stuff they do not require.
That is OK if all of the created binaries end up in the same binary
package. If not, you get (thanks to dpkg-shlibdeps) run-time
dependencies that are not needed, bloating the dependency tree and
dragging in more software than would be strictly needed.
This problem becomes worse by people copying over build systems from one
application to another, or using Makefile.am as a write-only file (ie
adding something whenever a new dep is created, but never removing
stuff). The usage of libtool and pkg-config combined with lazyness and
incompetence also adds to these problems. [1]
checklib is useful to detect such problems and works well. I have no
idea what gave you the idea that minimizing the build-depends line is
the point here - it simply isn't.
Marc
Footnotes:
[1] One of the uglier examples:
http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
--
BOFH #34:
(l)user error
Attachment:
pgpoz9ctv_R15.pgp
Description: PGP signature