Re: Documenting the (dynamic) linking rules for symbol versioning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux