This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Documenting the (dynamic) linking rules for symbol versioning
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