To: None <tech-userlevel@NetBSD.ORG>
From: Paul Kranenburg <firstname.lastname@example.org>
Date: 03/21/1998 01:02:49
Here are some thoughts on how to get the run-time linker involved in
shared library symbol versioning. The idea is to have ld.so lookup
symbols based on the `major version' requirement of the program that
wants to use the library. The shared library would retain old
interfaces (functions or data) after a change that requires a major
number update - much as it does now using __RENAME - and ld.so would
know how to retrieve the old versions for programs that were linked
with a previous major version number.
I see several ways to go about this:
(1) keep an explicit version number for all symbols that goes
into the library's exported symbol table. This requires
changes to ld(1) to generate the symbol table version numbers
and a way to specify them conveniently, especially for
the "compatibility" symbols you want to retain.
(2) rename compatibility symbols in a way that encodes the
major version they belong to and have ld.so search for
those symbols instead whenever necessary, i.e. when the
client (main program or other shared library) expects
a previous interface. If such a munged symbol is not
present, assume nothing has changed, and proceed as usual.
This approach can be implemented by changes to the
run-time linker only and a convention on the renaming
Example: `_foo' undergoes a major change. The current major
number is 12. The old definition is retained as symbol
`__foo_$m12', using e.g.
<typedef> __foo_12 asm("__foo_$m12");
`_foo' is changed to whatever is needed and the major number
is then updated to 13.
Thus, the magic ld.so would be looking for when asked to
resolve a symbol for a program compiled with major 12 would
consist of a prependend `_' and an appended `_$m12'.
(3) automatically load a compatibility shared library containing
exactly the symbols that changed in a `major number' upgrade.
Using the same example, `_foo' version 12 would move into,
say, libX.so.compat.12.0, which is loaded on demand by ld.so,
and put in front of the library search list. Doing this
might put some strain on ld.so if two or more major numbers
are mixed (e.g. because of `cascading' libraries that
reference different major numbers in their own dependencies).
With a bit of luck, one of these schemes might enable the elimination of
the libraries' major numbers in the file name altogether.
Please share your ideas/opinions...