Documenting the (dynamic) linking rules for symbol versioning

[Michael Kerrisk (man-pages)]

Hi Florian,

Thanks for your answers.

On 04/19/2017 05:48 PM, Florian Weimer wrote:
> On 04/19/2017 05:07 PM, Michael Kerrisk (man-pages) wrote:
>>     Am I right about my rough guess for the rationale for point 6,
>>     or is there something else I should know/write about?
> 
> We currently have a bug where the symbol resolution depends on the order 
> of alternatives along a hash bucket list:
> 
>    <https://sourceware.org/bugzilla/show_bug.cgi?id=12977#c2>

Okay.

> Another open problem is what happens when a versioned symbol moves from 
> one DSO to another.  This is not a problem for unversioned symbols, but 
> we currently have a soname check for versioned symbols.  This is rather 
> odd because this check isn't used to accelerate lookups.  It does not 
> prevent symbol interposition from other DSOs, it merely introduces 
> spurious failures.

I have a vague recollection that this problem has been around for a
very long time, right?


>> 7. The way to remove a versioned symbol from a new release
>>     of a shared library is to not define a default version
>>     (NAME@@VERSION) for that symbol. (Right?)
>>
>>     In other words, if we wanted to create a VER_4 of lib_ver.so
>>     that removed the symbol 'abc', we simply don't create use
>>     the usual asm(".symver") magic to create abc@VER_4.
> 
> You still need to use .symver, but with a @ version instead of a @@ version.

Why is that? What functionally is the difference between
having no .symver and a .symver with an @ version? (I tried
both, and they *both* result in undefined symbol errors from
ld(1), as I expected.

Cheers,

Michael



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