shared libraries, when to use them
Benson I. Margulies
benson at odi.com
Sun Jun 23 06:13:20 AEST 1991
In article <8448 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>
> >You can't, because SunOS doesn't have shared libraries. (What it does
> >have is shared object files. What's the difference? You can link in
> >part of a library without linking in the rest, among other things.)
>
>Just out of curiosity, who *has* implemented shared libraries?
>("Multics" is, unless I misremember, not the correct answer.)
What could "linking in part of a library" mean?
If this question is meaningful, Multics is the answer. Even SunOS gets
partial credit, as does AIX, perhaps.
The SunOS dynamic linker, at program startup, runs around and potches
with all of the shared objects referenced in the __DYNAMIC structure
of the executable, and and recursively in the library. It resolves all
the data references, and leaves the function references for later. So
while mmap's of the entire shared object happen, there is some
spurious paging. Since link resolution is left-to-right, a
further-left shared object can always replace symbols in one to the
right. The search list (LD_LIBRARY_PATH) is only for libraries, not
for names, so that limits the degree to which SunOS qualifies.
When a Multics process is born, no links are snapped. Individual
function and data items are found and linked in as referenced. There
is no such thing as a "library" as a fundamental concept. Reference
foo$bar? Search for an object file named foo in the current search
list with an entrypoint named bar. The object files in question are
the equivalent of .o files on Unix -- no ld need. A "binder" is
available to speed things up by lumping them together.
AIX has the characteristic that a shared library is a .o that may be
contained in a .a! So libc.a on AIX contains one shared object and a
bunch of statically linked .o files. On the other hand, AIX forces
much more of the resolution process to be completed at ld time.
--
Benson I. Margulies
More information about the Comp.unix.programmer
mailing list