[OpenAFS-devel] Re: [OpenAFS] jafs et al

Jeffrey Hutzelman jhutz@cmu.edu
Fri, 16 Mar 2007 15:13:13 -0400


On Friday, March 16, 2007 11:40:36 AM -0700 Russ Allbery <rra@stanford.edu> 
wrote:

> Chaskiel M Grundman <cg2v@andrew.cmu.edu> writes:
>> Russ Allbery <rra@stanford.edu> 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