Unreferenced Libraries?

[Walter Hurry]

On Mon, 07 Jan 2013 15:32:21 +0000, Matthew Seaman wrote:

> 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.

Oh, I see. They're OK then, and should simply be left well alone.

>> 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.

Ah, right. Thanks.