There is no simple pat answer, unfortunately, to either of the
questions.  (A lot depends on exactly how the objects were built and how
they are being loaded.)

Does it help if I observe that, in general, the primary arbiter of
whether a shared library dependency is resolved by a given object is
supposed to be the SONAME field (if any) in the dynamic section?

As a result of this observation, it is not supposed to be the case that
simply renaming a file would allow you to resolve a missing shared
library; nor should adding that same un-renamed file to the LD_PRELOAD
environment.  In both cases the reason is the same: the name assigned to
the object internally (the SONAME) would not be that of the object
listed in the NEEDED field.

That being said, I don't think our loader ever bothers to check if the
SONAME of the object loaded matches the one it was looking for in the
first place, so long as it loaded successfully.  So, practically
speaking, I think that renaming (or sym/hard linking) the file probably
would work, but it would be a bug if it did and I don't think I'd rely
on it ;-)

[ Full disclosure: I'm no expert on the loader. ]

On Wed, 2009-03-25 at 19:03 -0400, Dave Bott wrote:
> Customer wants to know if the dll version value is stored internally somewhere in the dll , other than just in the 
name.
> I don't think so, but I'm not sure...
> 
> Is it just used to create the suffix part of the library name, or is there more to it ?
> e.g. If you rename a .so.1 to .so.2, (ignoring the fact that one shouldn't do this), will it now be a .2 to any 
application that tries to use it, or does it retain some .1 ness (that is directly checkable by an app.).
> 
> Hope that's clear...
> 
> Thanks
> 
> Dave
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25266
>