Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!boulder!sunybcs!
bingvaxu!leah!itsgw!nysernic!rutgers!bellcore!tness7!mechjgh
From: mech...@tness7.UUCP (Greg Hackney )
Newsgroups: comp.sys.pyramid
Subject: shared libraries on Pyramid 9820 OSx4.1
Message-ID: <532@tness7.UUCP>
Date: 13 Apr 88 02:57:01 GMT
Lines: 20
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)
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!csg
From: c...@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.sys.pyramid
Subject: Re: shared libraries on Pyramid 9820 OSx4.1
Message-ID: <19461@pyramid.pyramid.com>
Date: 13 Apr 88 17:10:27 GMT
References: <532@tness7.UUCP>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 74
In article <5...@tness7.UUCP> mech...@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>