Shared Libraries - Your Thoughts Wanted
Craig Ruff (cruff@niwot.scd.ucar.EDU)
Thu, 28 Sep 1995 09:31:00 -0600 

I'm looking into implementing shared libraries.

If someone else is well along the way to getting this done - let me know so
I don't duplicate the effort.

Otherwise, I have some questions that others may have an opinion about.

How important do you think it is to duplicate how OSF/1 (DEC Unix) implements
shared libraries? Is running OSF/1 shared executables really that important?

How committed are you to the ECOFF executable format? Would you be adverse
to adopting ELF so we can take advantage of the (apparently) simple to use
shared library code that exists for ELF?

Craig Ruff NCAR cruff@ncar.ucar.edu
(303) 497-1211 P.O. Box 3000
Boulder, CO 80307

Re: Shared Libraries - Your Thoughts Wanted
Linus Torvalds (Linus.Torvalds@cs.helsinki.fi)
Fri, 29 Sep 1995 07:37:17 +0200 

Craig Ruff: "Shared Libraries - Your Thoughts Wanted" (Sep 28, 9:31):
> I'm looking into implementing shared libraries.

Great!

> How important do you think it is to duplicate how OSF/1 (DEC Unix) implements
> shared libraries? Is running OSF/1 shared executables really that important?

Linux already does run OSF/1 shared libraries, using the OSF/1
/sbin/loader program etc. 

We don't really need to try to make linux shared libraries compatible
with the OSF/1 ones: as far as I know, nobody has good documentation on
the OSF/1 shared libraries, and I ended up doing the OSF/1 binary
compatibility by writing a special loader of my own and looking at what
OSF/1 put on the stack.. 

I wouldn't mind it if OSF/1 was able to run linux binaries (even shared
ones), but quite frankly, with the lack of documentation I don't really
see that as an option. Besides, some linux system calls still wouldn't
be supported under OSF/1 (linux' getdents() would be used by the shell
for filename expansion etc). 

> How committed are you to the ECOFF executable format? Would you be adverse
> to adopting ELF so we can take advantage of the (apparently) simple to use
> shared library code that exists for ELF?

I'd suggest keeping to ECOFF (which is essentially a.out + small file
headers) until we know what the status of ELF is on the alpha. It would
be silly to have two different and incompatible ELF implementations
(anybody know if OSF/1 is defined now?). 

How about just using the original Linux a.out-type shared libraries? The
only kernel thing you need to do is just to add the "uselib()" system
call to arch/alpha/kernel/entry.S (I actually did that now, so as of
1.3.31, the alpha will have "sys_uselib()" as system call #313). 

The a.out fixed entry-points etc table building stuff is slightly
painful, and you'd need to port the changes made to the linux linker for
it (the "tools" directory of a linux GCC site, I do believe), but it
shouldn't be too bad. Knock wood. (I certainly have been too lazy to
even look into it to any great degree). 

Linus

Re: Shared Libraries - Your Thoughts Wanted
Jon 'maddog' Hall, USG Product Management (hall@zk3.dec.com)
Fri, 29 Sep 95 10:03:24 -0400 

Hi,

Normally I stay out of the technical discussions, but this one hits close to
home, so I will throw in my two cents.

I advocate ELF shared libraries. I see that the Intel Linux seems to be going
in that direction, and from a compiler and debugger viewpoint it would be
easier for the people who develop such things to have ONE shared library
and object code format for all Linux systems.

As to the binary compatibility with Digital UNIX I have several thoughts:

1) I have been uncomfortable for some time about having staticly linked
Digital UNIX binaries running on Linux. From a strictly legal standpoint
this means that you have royalty bearing code running on an unlicensed system.
This has not been an issue for the systems inside Digital, nor for some of
the ones we have sent out to some developers, because they were licensed to
run Digital UNIX. As time goes on, however, there will be more and more
system boards with *no* license associated with them, and the legal
implications are important. Understand that as a Digital Marketing Manager
I do not care one whit if Linux Alpha "usurps" Digital UNIX code. But the
people *we* license *our* code from may indeed care.

2) Statically-linked binaries work because the number of system calls are
few, and easily duplicated. I did a study a short time ago, and between
BSD 4.3 and System V.3, there were 134 system calls, of which 133 were exactly
the same. However, there were 1024 library routines (without X11, NFS, etc.)
and of that only 743 were "the same" (this study was only the syntax and
symantics of the call, not the side-effects). Ergo Linux systems trying
to use dynamically-linked Digital UNIX libraries would be doomed to failure,
unless a LOT more work went in.

3) It would be easier (legally) to create a "Linux Environment" on top of
Digital UNIX, by taking the Linux shared libraries and the Linux loader over 
to Digital UNIX than it would to do vice-versa. This has been a "side plan"
of mine all along. Of course for the "Linux Environment" we would ship all the
sources, copyrights, etc. And we would put the entire workings of the
environment out on the net. But as a "proprietary" (I hate that word)
operating system, we can add features like this which treat a particular
market, and allow the ISVs to build their applications for both Linux Alpha
and Digital UNIX on a Linux Alpha box, assuming the facilities they need are
in Linux Alpha. Digital UNIX *does* have some facilities that Linux may
not have for a while (such as SMP, soft realtime) and some things it may
never have (B1 security) due to lack of interest in the development community.
These features have APIs that will probably never appear on Linux.

If we create this "Linux Environment" on Digital UNIX, we would simply change
the loader to accept the ELF shared libraries as well as our current
ECOFF format.

I feel that the "Linux Environment" would give the largest installed base of
Alpha Linux/UNIX systems for the ISVs to target, which would help both
operating systems.

Of course all of this is from a "marketing type" who has not written a real
device driver since the days of the PDP-8, but I welcome comments.

And of course it is *your* operating system, and I am just an onlooker (and
user).

md
===============================================================================
Jon "maddog" Hall Senior Leader
Mailstop ZK03-2/U15 UNIX Software Group
Digital Equipment Corporation Internet: maddog@zk3.dec.com
110 Spit Brook Rd. Voice: 603.881.1341
Nashua, N.H. 03062-2698 Fax: 603.881.6059