Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!bootme.auspex.com!guy From: guy@bootme.auspex.com (Guy Harris) Newsgroups: comp.sys.pyramid Subject: Re: Pyramid Support of Shared Libraries Message-ID: <8908112239.AA00198@bootme.auspex.com> Date: 11 Aug 89 22:39:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 > 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).