On Wed, 30 May 2007 22:58:38 +0200, Marc 'HE' Brockschmidt <email@example.com> said:
> Manoj Srivastava <firstname.lastname@example.org> writes:
>> On Wed, 30 May 2007 18:28:43 +0200, Raphael Hertzog
>> <email@example.com> 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 still implies that the tool should be working on a per
package basis, not on a per binary basis.
> 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. 
> checklib is useful to detect such problems and works well.
Hmm. We obviously differ on the definition of "well". Anyway,
if you want to use a per binary implementation, instead of a per
package bit that can be run at package build time as a sanity check,
What I find more useful is to look at all undefined symbols in
all ELF objects in the tree, then look at all the libraries linked in;
and see if there are some libraries that do not provide any of the
undefined symbols -- for that would represent uneeded run time
dependencies (_and_ unneeded build dependencies, in most of the cases I
have dealt with).
Now optimizing the linkages of each individual binary might be
also nice; but it does not affect build dependencies or run time
dependencies; so I don't care to look at a per binary report. In other
words, if binary foo links with libfoo1; and binary bar links with
libfoo1 and libbar1; all I care about is that there should be no
spurious dependency on libbar1; ad not build dependency on libbar1-dev.
I don't really care if bar might or might not need to be linked
with ibfoo1; since the package also contains a binary foo that needs to
link with libfoo1 anyway -- all it means is that startup for bar would
be imperceptibly slower, and does not drag in more software than needed.
During the Middle Ages, probably one of the biggest mistakes was not
putting on your armor because you were "just going down to the corner."
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C