Documenting the (dynamic) linking rules for symbol versioning

[Michael Kerrisk (man-pages)]

Hi Florian,

On 04/28/2017 04:19 PM, Florian Weimer wrote:
> 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.

Yep, that's what I mean...

> If I understand you correctly, you want to remove xyz from the API.  

Yep.

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

Yes. I think we understood the same thing just from slightly different
perspectives. I wasn't sure though, because I'm not completely secure in
my knowledge of the details.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/