>From the ldd man page, there is a -u for "Unused direct dependencies".<br><br>root@salmon:~# ldd /bin/ls<br>        linux-vdso.so.1 =>  (0x00007fff6c5fe000)<br>        librt.so.1 => /lib/librt.so.1 (0x00007f1263fde000)<br>
        libselinux.so.1 => /lib/libselinux.so.1 (0x00007f1263dc2000)<br>        libacl.so.1 => /lib/libacl.so.1 (0x00007f1263bbb000)<br>        libc.so.6 => /lib/libc.so.6 (0x00007f1263859000)<br>        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f126363d000)<br>
        /lib64/ld-linux-x86-64.so.2 (0x00007f12641e7000)<br>        libdl.so.2 => /lib/libdl.so.2 (0x00007f1263439000)<br>        libattr.so.1 => /lib/libattr.so.1 (0x00007f1263235000)<br><br>root@salmon:~# ldd -u /bin/ls<br>
Unused direct dependencies:<br>        /lib/librt.so.1<br>        /lib/libselinux.so.1<br>        /lib/libacl.so.1<br><br>Maybe that is what you need?<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 3:45 PM, Robert P. J. Day <span dir="ltr"><<a href="mailto:rpjday@crashcourse.ca">rpjday@crashcourse.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
  i'm looking at an executable that was built with a couple dozen "-l"<br>
references to refer to shared libs to be linked at run time.  but only<br>
a few of those libs are actually used -- the list of libs was copied<br>
and pasted and is *way* overkill, but if you list them at compile<br>
time, they're going to show up via "ldd" in the final executable.<br>
<br>
  is there a way to identify which shared libs are actually being<br>
*used* by an executable, and which are superfluous and can be dropped<br>
from the list of libs during the compile step?<br>
<br>
  they don't hurt, of course, except for taking up a small amount of<br>
space in the executable, but if they're not necessary, i'd rather they<br>
not be there.  thanks.<br>
<br>
rday<br>
--<br>
<br>
========================================================================<br>
Robert P. J. Day<br>
Linux Consulting, Training and Annoying Kernel Pedantry:<br>
    Have classroom, will lecture.<br>
<br>
<a href="http://crashcourse.ca" target="_blank">http://crashcourse.ca</a>                          Waterloo, Ontario, CANADA<br>
========================================================================<br>
<br>
_______________________________________________<br>
<a href="http://kwlug-disc_kwlug.org" target="_blank">kwlug-disc_kwlug.org</a> mailing list<br>
<a href="http://kwlug-disc_kwlug.org" target="_blank">kwlug-disc_kwlug.org</a>@<a href="http://kwlug.org" target="_blank">kwlug.org</a><br>
<a href="http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. --   Leonardo da Vinci<br>