gregg@dduck.ctt.bellcore.com (Victor Scott Gregg) (08/05/89)
Question for the net: Could some one send me a pointer to information on Pyramid support for shared libraries? Is this a 5.0 feature? Is there a technical paper or documentation available? I'm also interested in a more general discussion of shared libraries in UNIX. Is there a USENIX or AT&T paper on the subject? Thanks, Victor S. Gregg gregg@ctt.bellcore.com _ _ _ _ _ _ 444 Hoes Ln (1C-206) uunet!bellcore!ctt!gregg |_| |_ | | | | | |_| |_ Piscatway, NJ 08854 (201) 699-4596 |_| |_ |_ |_ |_ |_| | \ |_ Standard Disclaimer: M Y opinions only, N O T those of my employer.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (08/06/89)
In article <17347@bellcore.bellcore.com> Victor Scott Gregg writes: >Question for the net: Save some net bandwidth, and ask your salescritter. >Could some one send me a pointer to information on Pyramid support for >shared libraries? Pyramid does not support shared libraries in either OSx 5.0 (current) or 5.1 (planned). It is a win on smaller systems, like workstations and 3B2's, but not as important on a large system as a lot of other things we could be working on. Implementing shared libraries would mean changing binary file formats, something that was a more-pain-that-gain proposition. Note that binaries from OSx 2.1 will still run under OSx 5.0, five years later, even on the MIServer. Not forcing the customers to recompile everything at every major release is something that has been pretty important to the company. <csg>
gregg@dduck.ctt.bellcore.com (Victor Scott Gregg) (08/07/89)
In article <79957@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >In article <17347@bellcore.bellcore.com> Victor Scott Gregg writes: >>Question for the net: > >Save some net bandwidth, and ask your salescritter. > Save some net bandwidth, reply instead of follow-up. >>Could some one send me a pointer to information on Pyramid support for >>shared libraries? > >Pyramid does not support shared libraries in either OSx 5.0 (current) >or 5.1 >(planned). I suspect that most customers haven't moved to 5.0 yet, but thanks for the info that shared libraries are not supported in 5.0 or 5.1. >It is a win on smaller systems, like workstations and 3B2's, but not as >important on a large system as a lot of other things we could be working on. I think that there are benefits to supporting shared libraries which are independent of machine size. (IBM MVS/C supports shared libraries on 3090.) >Implementing shared libraries would mean changing binary file >formats, something that was a more-pain-that-gain proposition. Implementing shared-libraries would add a new binary format, but there is no reason that existing binaries could not be supported. >Note that binaries from OSx 2.1 will still run under OSx 5.0, >five years later, even on the MIServer. I agree that this is a good thing, but shared libraries could be implemented and new binaries required only if the customer wanted to take advantage of the feature. >Not forcing the customers to recompile everything at every major release >is something that has been pretty important to the company. Once shared libraries are available, it would be possible to make fixes to standard libraries without touching the application binaries. This is one of two main benefits of shared libraries. The other is to reduce the memory and paging requirements for application transactions which use common code. This seems like a WIN in the MISserver. > ><csg> Victor S. Gregg gregg@ctt.bellcore.com _ _ _ _ _ _ 444 Hoes Ln (1C-206) uunet!bellcore!ctt!gregg |_| |_ | | | | | |_| |_ Piscatway, NJ 08854 (201) 699-4596 |_| |_ |_ |_ |_ |_| | \ |_ Standard Disclaimer: M Y opinions only, N O T those of my employer.
eric@pyramid.pyramid.com (Eric Bergan) (08/09/89)
In article <17350@bellcore.bellcore.com> gregg@dduck.UUCP (Victor Scott Gregg) writes: >In article <79957@pyramid.pyramid.com> >csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > >>Implementing shared libraries would mean changing binary file >>formats, something that was a more-pain-that-gain proposition. > >Implementing shared-libraries would add a new binary format, but there >is no reason that existing binaries could not be supported. A new binary format has far reaching implications, however, since it then causes changes to the compilers, loader, ar, debuggers, etc. We had originally intended to implement System VR3-style shared libraries. But then SVR4 came out and completely changed (again) how shared libraries are to be handled. As we move to support SVR4, we will be supporting SVR4-style shared libraries, and making the necessary changes to the support tools. >Once shared libraries are available, it would be possible to make fixes >to standard libraries without touching the application binaries. This is one >of two main benefits of shared libraries. In fact, it also extends to system calls, since they are can then be handled by a shared library, and relinking the world is not necessary. We will be doing and supporting this with SVR4 support. >The other is to reduce the memory and paging requirements for application >transactions which use common code. This seems like a WIN in the MISserver. It should be noted that there is one loss with shared libraries: all references to external symbols end up going through an extra level of indirection. Depending on architecture, this can add several instructions to a variable reference, plus an additional memory reference which may or may not be in the data cache. It is yet to be determined what the performance penalty for this is. -- eric ...!pyramid!eric
rick@uunet.UU.NET (Rick Adams) (08/11/89)
> Once shared libraries are available, it would be possible to make fixes > to standard libraries without touching the application binaries. This is one > of two main benefits of shared libraries. Note that this also raises the problem of breaking existing binaries that depend on the 'old' behavior of the library routine. You have to be very careful about fixing shared library modules if you dont expect to break something that was already working. Version numbers are a start, but then you dont get the automatic update that you mentioned
guy@bootme.auspex.com (Guy Harris) (08/12/89)
> 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).