On Wed, 30 May 2007 22:58:38 +0200, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes: >> On Wed, 30 May 2007 18:28:43 +0200, Raphael Hertzog >> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]