Hi,
Inspired by http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html, I've had a patch for rpmlint in my local tree for a while which checks for unused direct shared library dependencies in shared libs.
I'm wondering whether this check is a good idea; I'm not an expert in this area and the check does produce quite a bit of output on some packages. Comments very much welcome. At the moment I'm leaning towards including this in the next rpmlint release anyway.
For the adventurous, grab the latest rpmlint from svn (see http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk/README.devel) and apply the attached patch to BinariesCheck.py.
Example output:
$ rpmlint krb5-libs | grep shlib W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkrb5support.so.0.1 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libk5crypto.so.3.0 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkdb5.so.4.0 /lib/libdl.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkdb5.so.4.0 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /usr/lib/libkrb5.so.3 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /usr/lib/libk5crypto.so.3 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /lib/libcom_err.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssapi_krb5.so.2.2 /lib/libdl.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssapi_krb5.so.2.2 /lib/libresolv.so.2 W: krb5-libs unused-direct-shlib-dependency /usr/lib/libdes425.so.3.0 /lib/libcom_err.so.2
$ rpmlint -I unused-direct-shlib-dependency unused-direct-shlib-dependency : The binary contains unused direct shared library dependencies. This may indicate gratuitously bloated linkage; check that the binary has been linked with the intended shared libraries only.
ville.skytta@iki.fi (Ville Skyttä) writes:
Inspired by http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html, I've had a patch for rpmlint in my local tree for a while which checks for unused direct shared library dependencies in shared libs.
I'm wondering whether this check is a good idea;
Generally yes; dynamically loaded modules are an exception, because their deps can be resolved by the loading lib/application already.
Another exception might be glib2 based applications/modules. There seems to be something wrong with its type system so that applications (which are not linked against glib2) misbehave when a dynamic module is linked against glib2. After unloading the module and loading it again, some types might not be registered right.
But these are minor issues only.
A more major one might be, how this kind of warning can be fixed. All major buildsystems (libtool, cmake) are creating such unused dependencies. Setting '-Wl,--as-needed' linkerflags might help with cmake, but fails horribly with libtool because it moves such linkerflags to the end of the cmdline.
I used some magic like
| sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool
after %configure. But it's not a panacea because it will not work for the exceptions above.
Enrico
On Sat, Jan 27, 2007 at 10:47:49AM +0200, Ville Skyttä wrote:
Hi,
Inspired by http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html, I've had a patch for rpmlint in my local tree for a while which checks for unused direct shared library dependencies in shared libs.
I'm wondering whether this check is a good idea; I'm not an expert in this
I am not an expert either but I think this is a very good idea. I have started to do this manually in all the reviews. I think it seems interesting to me for the following reasons:
* it seems to improve linking * it removes unneeded dependencies, so rpm/yum/... will likely be faster * rebuilt are not necessary when an indirect dependency ABI changes
In my opinion the best way to remove those unneeded dependecies is to
* use pkgconfig and .private apropriately in libraries * work with upstream such that packages that depend on the libraries use pkgconfig apropriately.
-- Pat
packaging@lists.fedoraproject.org
-
Enrico Scholz -
Patrice Dumas -
Ville Skyttä