Pyramid Support of Shared Libraries

[Guy Harris]

> Version numbers are a start, but then you dont get the automatic update
> that you mentioned

Well, yes, but I presume that's the reason you want version numbers - if
the library changes in a fashion that breaks old code, you *don't* want
an automatic update, since the applications containing the old code will
stop working....

The SunOS 4.x version number scheme, which will probably be the one used
in S5R4 as well, has "major" and "minor" version numbers.  The "major"
version number changes if the interface changes in an incompatible
fashion; the "minor" version number changes if the interface changes in
such a way that programs written to the new interface won't work when
run against the old shared library (e.g., because they depend on a
library routine added in the new version), but programs written to the
old interface should continue to work.

The run-time loader looks for shared libraries with the same major
version number as the one the program was built with; if it doesn't find
it, it prints an error and exits.  It looks for the one with the highest
minor version number it can; if that number is lower than the minor
version number of the one the program was built with, it prints an
error, but continues, in the hope that the user'll get lucky and the
program won't get tripped up by not finding a library routine (although
if the routine is missing, it'll fail later).

Of course, this doesn't help if 1) the program depended on some library
routine behavior that wasn't part of the interface or 2) the behavioral
change is the result of a bug, but there's not much that can help there
- both problems result from bugs, and you have to try to avoid
introducing bugs into both application and library code....  All shared
libraries do here is increase the number of system services to which you
dynamically bind - i.e., "/vmunix" no longer contains the only set of
dynamically-bound services (but with network services that wasn't true
anyway).