Re: checklib
On Wed, 30 May 2007 22:58:38 +0200, Marc 'HE' Brockschmidt <he@ftwca.de> said:
> 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 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. [1]
> 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,
great.
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.
manoj
--
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 <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: