On Friday, March 16, 2007 11:40:36 AM -0700 Russ Allbery <[EMAIL PROTECTED]>
wrote:
Chaskiel M Grundman <[EMAIL PROTECTED]> writes:
Russ Allbery <[EMAIL PROTECTED]> wrote:
I expect symbol versioning to do what symbol versioning does, namely to
provide a mechanism for maintaining a stable ABI even when introducing
new function signatures so that the library ABI doesn't have to be
changed
You should be aware that symbol versioning does not do this on solaris.
the notion of a library being able to export symbols with the same name
and different versions pointing at different addresses is a gnu LD
extension
(<http://www.linuxshowcase.org/2000/2000papers/papers/browndavid/brownda
vid_html/>. section 4.1 discusses the capabilities of sun and gnu LD.
section 4.2 explains sun's versioning policy, and why they don't need
the multiple-versions capability: once a function is considered
'public', sun never changes its function signature)
Hm, what *is* the use of symbol versioning on Solaris, then? Does it
still help with the case where two versions of the same library are loaded
into the running process?
No, but Sun's policy does that, by insuring that it never needs to happen -
the sonames of libraries pretty much never change, and the signature and
semantics of a symbol never change in a backward-incompatible way. So, as
long as you have a new enough version of each library, you're fine.
What Solaris symbol versioning does is let you define multiple interface
versions, and indicate which symbols belong to which interface versions.
This allows the linker to generate proper version dependencies, and the
runtime linker to verify that you have a new enough library, both without
being overly restrictive about version matching. However, you cannot have
multiple versions of a symbol in the same library, or in the same process.
If something changes in a backwards-incompatible way, its name must also
change.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
