Unreferenced Libraries?

[Matthew Seaman]

On 07/01/2013 14:27, Walter Hurry wrote:
> 9.1-RELEASE on amd64.
> 
> libchk reports the following libraries (among others) as unreferenced:
> 
> /usr/lib/libBlocksRuntime.so.0
> /usr/lib/libform.so.5
> /usr/lib/libformw.so.5
> /usr/lib/libgpib.so.3
> /usr/lib/libgssapi_ntlm.so.10
> /usr/lib/libgssapi_spnego.so.10
> /usr/lib/libhistory.so.8
> /usr/lib/liblwres.so.80
> /usr/lib/libmenu.so.5
> /usr/lib/libmenuw.so.5
> /usr/lib/libmilter.so.5
> /usr/lib/libpanelw.so.5
> /usr/lib/librpcsec_gss.so.1
> /usr/lib/libstdbuf.so.1
> /usr/lib/libsupc++.so.1
> /usr/lib/libthread_db.so.3
> 
> All these are part of base.
> 
> I note that in each case there is a <name>.so symlink pointing to the 
> relevant library, as is, I believe, accepted best practice.

Yes, that's right.

> Would I be correct in assuming that the reason libchk is reporting these 
> as unreferenced is that everything which is actually using them is 
> referencing the symlink?

Actually, it is probably reporting them because nothing is actually
using them.  libmilter.so.5 for instance won't have any consumers in the
base system (not even /usr/libexec/sendmail/sendmail) but it is provided
in case you want to install any mail filters from ports or otherwise.

> Or is libchk clever enough to resolve symlinks, and there is a different 
> reason?

The shlib sym-link without the ABI version number is generally only used
at compile-time.  Once the application has been linked, the dynamic
loader will require the shared library with appended ABI version.  There
are instances of things that look at first sight like a shared library,
but that don't have an ABI version no.  In general, these are not in
fact shared libraries, but loadable modules used by various specific
programs.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matthew at infracaninophile.co.uk