ruud@targon.UUCP (Ruud Harmsen) (01/08/90)
What exactly are shared libraries? What UNICes have them? Does it mean that frequently used libraries are no longer compiled into the executable, but reside only in the library? Does this save space on disk, or also at runtime, in core? Can you do it only with standard libraries, or also with your own? Is it any slower or faster than the normal way?
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/09/90)
In article <941@targon.UUCP> ruud@targon.UUCP (Ruud Harmsen) writes: >What exactly are shared libraries? What UNICes have them? Does it mean that >frequently used libraries are no longer compiled into the executable, but >reside only in the library? Does this save space on disk, or also at >runtime, in core? Can you do it only with standard libraries, or also with >your own? Is it any slower or faster than the normal way? You seem to have the right notion already. Shared libraries are pretty much standard on UNIX System V Release 3 and later, as well as on some UNIX-based systems for small (PC-like) environments. Space is definitely saved on disk and in general main memory demand is also reduced. Users can generally create their own shared libraries, but you need to work hard at doing it right, since the initial interfaces cannot be changed later without recompiling EVERY application that used the shared library. There is a very slight added cost in calling a shared library function, but it is almost always repaid by the overall reduced load on the system. One implementation technique is for there to be a vector of standard (shared) function pointers in a segment that is mapped at execution time into the same virtual space as the shared library implementation's vectors. Because the vectors are always at the same address, the library can be improved without requiring that existingt applications be relinked.
cpcahil@virtech.uucp (Conor P. Cahill) (01/09/90)
In article <941@targon.UUCP>, ruud@targon.UUCP (Ruud Harmsen) writes: > What exactly are shared libraries? What UNICes have them? System V.3+, Sun OS (not sure which verson) to name a couple. > Does it mean that > frequently used libraries are no longer compiled into the executable, but > reside only in the library? Yup > Does this save space on disk, Yup, lots. > or also at runtime, in core? Yup > Can you do it only with standard libraries, or also with > your own? Both. > Is it any slower or faster than the normal way? Slower link and program initialization, but from then on execution time should be the same. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
vinoski@apollo.HP.COM (Stephen Vinoski) (01/09/90)
In article <1990Jan9.003208.6061@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <941@targon.UUCP>, ruud@targon.UUCP (Ruud Harmsen) writes: >> What exactly are shared libraries? What UNICes have them? > >System V.3+, Sun OS (not sure which verson) to name a couple. > Let's not forget Apollo's Domain/OS. Contrary to popular belief, Sun did *not* invent shared libraries - honest! :-) -steve | Steve Vinoski | Hewlett-Packard Apollo Div. | ARPA: vinoski@apollo.com | | (508)256-6600 x5904 | Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | | "My wife left me for a tractor salesman. I didn't know what to do when I | | found the John Deere letter..." |
dbrooks@osf.org (David Brooks) (01/10/90)
In article <47eed587.20b6d@apollo.HP.COM>, vinoski@apollo.HP.COM (Stephen Vinoski) writes: > In article <1990Jan9.003208.6061@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: > >In article <941@targon.UUCP>, ruud@targon.UUCP (Ruud Harmsen) writes: > >> What exactly are shared libraries? What UNICes have them? > > > >System V.3+, Sun OS (not sure which verson) to name a couple. > > > > Let's not forget Apollo's Domain/OS. Contrary to popular belief, Sun did *not* > invent shared libraries - honest! :-) Of course, there were shared libraries long before Un...I mean Posix-like-systems...had them: RSX-11M. SDS (later XDS) CP-V and its predecessors. the above used a fixed-place transfer vector. Primos V-mode, using name lookup and runtime pointer patching. People even older than me can no doubt go further back. -- David Brooks dbrooks@osf.org Open Software Foundation uunet!osf.org!dbrooks
friedl@mtndew.UUCP (Steve Friedl) (01/10/90)
Ruud Harmsen writes: > Is it [shared libraries] any slower or faster than the normal way? Conor P. Cahill writes: > Slower link and program initialization, but from then on execution time > should be the same. I don't know about SunOS with dynamic shared libaries, but the static shared libraries provided with System V don't have any kind of linking operation at runtime. The functions in the shared library live at fixed addresses within the virtual address space, and the locations of same are set to absolute values within the program using them. At runtime, the executable is loaded normally, and calls to the shared library routines depend on the routines living where they are supposed to (they *better* be there). The sizes of a traditional "hello, world" example on my 386 running Sys V Rel 3.2: Shared: 460 + 1788 + 2552 = 4800 Nonshared: 10720 + 3044 + 2552 = 16316 Sys V Release 4.0 will probably have dynamic libraries. Steve -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy 714 544 6561 voice / 714 544 6496 fax / uunet!mtndew!friedl / friedl@vsi.com "PostScript wizard in training." - me
olapw@olgb1.oliv.co.uk (Tony Walton) (01/10/90)
ruud@targon.UUCP (Ruud Harmsen) writes: >What exactly are shared libraries? What UNICes have them? Does it mean that >frequently used libraries are no longer compiled into the executable, but >reside only in the library? Does this save space on disk, or also at >runtime, in core? Can you do it only with standard libraries, or also with >your own? Is it any slower or faster than the normal way? Well, I'll probably get flamed for oversimplifying this, but what the hell... As you say, shared libraries aren't compiled into the executable, but reside in one place only on the disk. After the machine is booted, the first process to require a shared library will cause the library to be loaded into memory from disk; the library will remain loaded as long as at least one process requires it. Any process which requires the shared library will use the copy in memory rather re-loading the library from disk, if the library is already loaded. This means that 1) an executable linked to use shared libraries will (probably*) take up less space on disk and in RAM than one using archive (compiled-in) libraries and 2) will load slightly faster (because it's smaller). 3) changes, debugging, etc applied to the shared library will automatically be applied to all executables which use the library without the need to recompile each module. This also means that bugs introduced into the shared library will automatically appear in all executables etc etc :-) * Note the "probably" above there - if the executable uses very few library functions and/or very small library functions, the overhead for the shared library linkage may well be bigger than the library functions themselves, making the executable bigger when linked to use shared libraries than when linked standalone. You can (on AT&T Unix, at least) create your own shared libraries quite simply - basically you need to compile your functions as normal and create a table which states where in virtual RAM the libraries are to be loaded. Take care with this as some areas are reserved for things like libc_s (the shared version of the normal libc.a) and networking libraries (AT&T provide libnsl_s - Network Support Library which includes the TLI functions). Other areas are reserved for graphics libraries, statistics libraries, etc. The AT&T Programmer's Guide has quite a large section on shared libraries, how to create them, when not to use them, and so on. The problems mentioned above regarding address overlap apply to *statically* linked shared libraries only - *dynamically* linked shared libraries will be avialable under Unix System V rel 4.0; they are based on the SunOS 4.0 implementation and remove the requirement to bind libraries to fixed pathnames and fixed virtual addresses. -- Tony Walton, OEM/VAR Division, British Olivetti Ltd., 154-160 Upper Richmond Rd, LONDON, SW15 2FN. Tel: (+44) 1 789 6699 Telefax: (+44) 1 785 6670 Telex:27258 Uucp : { ukc!uel | mcvax!olnl1 | ihnp4!cuuxb | iconet | olhqma } !olgb1!olapw olapw@olgb1.oliv.co.uk
dave@micropen (David F. Carlson) (01/11/90)
In article <323@mtndew.UUCP>, friedl@mtndew.UUCP (Steve Friedl) writes: > Ruud Harmsen writes: > > Is it [shared libraries] any slower or faster than the normal way? > > Conor P. Cahill writes: > > Slower link and program initialization, but from then on execution time > > should be the same. > > ... > library live at fixed addresses within the virtual address space, > and the locations of same are set to absolute values within the > program using them. At runtime, the executable is loaded normally, > and calls to the shared library routines depend on the routines > living where they are supposed to (they *better* be there). > Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy Having written a SVr3 graphics shared lib, I believe that Conor is positing that since the shared lib_s.a at ld(1) time will have more symbols it will take longer to load that the normal lib.a. I have not found this to be the case. Because the lib_s.a is *much* less in size, ld(1) has less object code to read (and re-read...) than with lib.a. I have found that a 2X size reduction is *much* faster and well worth the additional symbols the loader must crunch. Program initialization, (contrary to Mr. Friedl), will initialize all *external* symbols within the lib_s (living at a fixed virtual address.) This time is usually small. However, the entire shared library data section is private to each process using the library and must be paged in as normal. This will almost always dominate initialization time, although it should be no slower than normal data section loads. At runtime all shared library calls and all externals used/called by the shared library itself will have one extra level of indirection. This will slow them down by whatever that extra indirect costs on your host. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
CCDN@levels.sait.edu.au (david newall) (01/12/90)
vinoski@apollo.HP.COM (Stephen Vinoski) writes: > Contrary to popular belief, Sun did *not* invent shared libraries - honest! UCSD p-System had the first implementation of shared libraries I know of. David Newall Phone: +61 8 343 3160 Unix Systems Programmer Fax: +61 8 349 6939 Academic Computing Service E-mail: ccdn@levels.sait.oz.au SA Institute of Technology Post: The Levels, South Australia, 5095
barmar@think.com (Barry Margolin) (01/15/90)
In article <6256@levels.sait.edu.au> CCDN@levels.sait.edu.au (david newall) writes: >UCSD p-System had the first implementation of shared libraries I know of. Did the p-System predate Multics, which was developed in the mid-60's? It has had dynamically-linked, shared libraries for over 20 years. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
sl@van-bc.UUCP (Stuart Lynne) (01/16/90)
In article <32873@news.Think.COM> barmar@think.com (Barry Margolin) writes: >In article <6256@levels.sait.edu.au> CCDN@levels.sait.edu.au (david newall) writes: >>UCSD p-System had the first implementation of shared libraries I know of. > >Did the p-System predate Multics, which was developed in the mid-60's? It >has had dynamically-linked, shared libraries for over 20 years. UCSD Pascal 1.5 was first made available publicly in the spring of 1978. I think it had been in use and development for about two years at UCSD prior to that. I think we could revise the above statement read "the first implementation of shared libraries on a PC". -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
CCDN@levels.sait.edu.au (david newall) (01/18/90)
In article <32873@news.Think.COM>, barmar@think.com (Barry Margolin) writes: > In article <6256@levels.sait.edu.au> CCDN@levels.sait.edu.au (david newall) writes: >>UCSD p-System had the first implementation of shared libraries I know of. > > Did the p-System predate Multics, which was developed in the mid-60's? I don't recall when UCSD first did the p-System -- I think it was early '70s. I can't even say for certain that p-System version-I had shared libraries (I know version II did), although I do seem to recall that it did. Anyway, it sounds like Multics's shared libraries pre-date UCSD's. David Newall Phone: +61 8 343 3160 Unix Systems Programmer Fax: +61 8 349 6939 Academic Computing Service E-mail: ccdn@levels.sait.oz.au SA Institute of Technology Post: The Levels, South Australia, 5095