Documenting the (dynamic) linking rules for symbol versioning

[Florian Weimer]

On 04/20/2017 04:07 PM, Michael Kerrisk (man-pages) wrote:

> Suppose we have a version script:
> 
> [[
> VER_1 {
>      global: xyz;
>      local: *;
> };
> 
> VER_2 {
>      ...
> } VER_1;
> 
> VER_3 {
>      ...
> } VER_2;
> ]]
> 
> And we have a C file that defines xyz@VER_1, xyz@VER_2, and xyz@VER_3.
> 
> Now suppose that we want to add a VER_4 tag to the map, and a new
> function, abc(), to our C source file (so that we will end up with
> a symbol abc@VER_4).
> 
> Suppose also that in programs that link against the new library (built
> with the VER_4 map), we want the symbol xyz() to no longer be accessible
> to ld(1). There appears  to be two ways to do this:
> 
> * Don't define an xyz@VER_4 (or, of course, xyz@@VER_4) in our
>    C source file.
> * Define an xyz@VER_4.

Okay, I think I'm getting our misunderstanding now.

If xyz was previously part of the public API, then one of the versions 
xyz@VER_1, xyz@VER2, xyz@VER_3 must have been a default version, so 
probably xyz@@VER_3.

If I understand you correctly, you want to remove xyz from the API.  So 
we need to get rid of the default version.  In this case, I think most 
people just use a .symver directive with a non-default versions, in this 
example xyz@VER_3.  This overrides the version script as far as this 
particular symbol is concerned.

There is no need to introduce VER_4 for this symbol, default or not.

Does this clarify matters?

Thanks,
Florian