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

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

-pk