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