mechjgh@tness7.UUCP (Greg Hackney ) (04/13/88)
I rec'd this question from a programmer, and don't know the answer. Can someone answer it? Thanks in advance. -- Greg Hackney Southwestern Bell Telephone Co. {ihnp4 | bellcore}!tness7!mechjgh . The programmers guide to SVR3 mentions shared . libraries available in this release of UNIX . . Using shared libraries when compiling applications . holds several advantages over using the standard archived libraries. . . The standard c library is supposed to be available . in shared form in /shlib/libc_s. . . Unfortunately, this directory is not on the Pyramid. . I thought OSx was supposed to be SVR3. (as well as BSD)
hedrick@athos.rutgers.edu (Charles Hedrick) (04/13/88)
As far as we can tell, OSx 4.1 is SVr2. However it adds those SVr3 extensions that are likely to affect the ability to import application code. A full SVr3 port is quite an undertaking, and apparently they haven't had time to get it finished. OSx 4.1 is a compromise, intended to provide maximum compatibility at the application level, but to omit the things that are hairy to implement. In particular, shared libraries require a major reorganization of the virtual memory subsystem. One of the recent Usenix proceedings has papers from a number of vendors describing the rewriting that a number of them are doing in order to give their virtual memory subsystems the ability to handle things such as shared libraries and copy-on-write. It's non-trivial. Many vendors will not find it practical simply to adopt SVr3's implementation.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/14/88)
In article <532@tness7.UUCP> mechjgh@tness7.UUCP (Greg Hackney ) writes: >. The programmers guide to SVR3 mentions shared >. libraries available in this release of UNIX >. >. I thought OSx was supposed to be SVR3. (as well as BSD) It is, almost.... :-) Shared libraries and RFS are the two most visible pieces of SVR3 that are not available in OSx. RFS is not available because it would be a big job to port and *test*, and quite literally no one is asking for it. (Even the die-hard System V users run NFS.) Shared libraries *are* something customers are asking for, and it would be a big help now and even more in the future. The fundamental problem in bringing up shared libraries is that we cannot do it with our current BSD-derived (actually SunOS-derived) a.out file format. Either we would have to add extensions to BSD a.out files to support shared libraries, or switch to COFF. Switching to COFF has a number of advantages. All the SVR3 code is already written assuming COFF; we could drop it into OSx with few modifications. COFF is (on paper) more extensible than the BSD a.out; the sections are identified by simple character strings, so you can add new ones at will. Also, most of Pyramid's best customers (RBOCs) use the System V universe as or more heavily than the Berkeley universe, and would appreciate the SVR3 functionality of ld, ar, etc., that would be gained. The disadvantages are significant, too. COFF has used up all the fields for classes of objects, which I have been told will make it impossible for a COFF system to truly support ANSI C (which has new classes like const). We could rearrange COFF, but we'd be losing the easy portability we sought. Also, COFF would make the transition code in the kernel vastly more difficult. Pyramid makes a big issue of binary portability, and the kernel that supported shared libraries would still have to run the old a.out files, at least for one major release. If we simply beat up the BSD a.out (which we have done before), then the transition code is simple: a new magic number, look for new sections. Changes to the compiler backend are simple, too. If we've switched to COFF, we need two completely different kernel loaders. And we would have to regression test *EVERYTHING* in the whole system, since I'm quite sure that a lot of code (especially Berkeley code) would break when a.out and library format changed. (I suspect much Berkeley code writes on areas that would become read-only in a shared-library environment.) But making a new BSD a.out that supports shared libraries means major changes to the SVR3 code, code which we don't understand as well as our own source. The final decision was no dicision, for now anyway. The advantages of shared libaries simply didn't outweigh the work required. It would have meant delays for products that were considered much more important: virtual and mirrored disk, new communications products, enhanced performance for Sysbase, diskless NFS, etc. There *will* be shared libraries some day, but not today. Parenthetical comment: The above paragraph also summaries my feelings on why the AT&T/Sun deal is foolish, and a threat entirely different from what most people think it is. No one of substance is demanding a merged UNIX -- it's all purists, hackers, and those who have positioned themselves specifically to take advantage of it. Programmer resources are *scarce*, and there are *LOTS* of more important things for UNIX developers to be spending time on than trying to fill in the gaps between UNIX variants! UNIX is at present a very mediocre commercial OS, but is so powerful and extensible that this could be remedied if anyone wanted to try. Contrary to what all the pundits are saying, I see the SVR4 project doing far more damage to the commercial success of UNIX than good, because important things won't get done, while trivial ones flail around in search of a goal they will never reach. Sun will go down in flames, AT&T will go out with a wimper, and some of the of the best and brightest minds in the country will have been wasted. When I consider the AT&T/Sun deal, it is not with fear (as many UNIX vendors see it) or joyfull anticipation (as USENET readers seem to see it), but with sadness at what could have been. <csg>
cal@pyrtech (Craig Alan Levin) (04/14/88)
I have resisted posting to this forum for so long, but since I am going away for a while, I guess it is okay. At least I will not be here to read the flak. In article <Apr.13.04.53.12.1988.24584@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >As far as we can tell, OSx 4.1 is SVr2. However it adds those SVr3 >extensions that are likely to affect the ability to import application >code. A full SVr3 port is quite an undertaking, and apparently they >haven't had time to get it finished. OSx 4.1 is a compromise, >intended to provide maximum compatibility at the application level, >but to omit the things that are hairy to implement. If you read your OSx 4.0 Release Bulletin (page 1-1) it tells you that: OSx 4.0 conforms to the Base System and Kernel Extension portions of AT&T's System V Interface Definition (SVID), Volume 3. These portions of the SVID include both kernel and library functions. The utilities of SVR3.1 have not been finished being ported. When a problem is found with a ATT universe utility, the first thing Sustaining Engineering (the bug fix folks in Field Engineering) do is check whether it is fixed in SVR3.1. If so, we do a 3 way compare of current product with it's ATT origin and SVR3.1, then determine if it is expedient to repair the problem or use the new merged code. If the latter is done, your PTFs are SVR3.1 code and the new code is released in the next available OSx release. In concert with the above, there is an R&D project to complete the port of all SVR3.1 utilities, but the whole Pyramid Software R&D group is smaller than the number of people at AT&T that work full time on just utilities. If there are specific problems that you may be having with any utilities, RTOC or pyrtech!bugs is the place to contact. This forum is fine for letting off steam, but will not generate any solutions. /|\ Departure 4/15/88 / | \ / | \ Plan: Head out the Golden Gate and / | \ turn left to a warmer climate. / | \ / | \ --------------- \___________/