A few days ago, I asked the advantages of using shared libraries over "static"
libraries. The main advantages are ( thanks to firstname.lastname@example.org ),
1. Memory footprint:
with a shared library, each task shares the same memory space
for the shared library. Less pages need to be in ram cutting down
paging and reducing the overall memory footprint. This is a big
2. Bug fixes.
A bug can be fixed in the library and all tasks see the fix without
having to relink them.
3. Disk size
Not linking in the code into every task can save much disk
space (an X task that is 30kb in shared form would be over 2MB
in regular form, that adds up)
Also, from email@example.com,
Well two are:
They are shared so only 1 copy need be in memory at a time even
if N programs are running that use the library.
Binaries compiled with shared libraries under SunOS are more
likely to run under Solaris 2 as-is.
Bugs in the shared libraries don't require recompiling all your
apps when they are fixed. I find that a semiadvantage because I
like the same binaries to work the same...bugs and all.
You get warning if you run a binary compiled under a more recent
revision on an older revision.
Not to mention disadvantages:
If a shared library is unreachable for some reason a whole
lot of stuff can break. That's why certain basic-necessity things
are in /sbin (statically compiled binaries).
A few braindead apps require a SPECIFIC revision of the libraries.
Not "version x.y or above" but "version x.y". This is usually
fixable with a symlink: the old name pointing to the new version.
Thanks to the following who responded:
_ /| Dave Haut
\,o.O' Sys Admin
=(___)= EXAR Corporation
(408) 434-6400 x3462
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:33 CDT