Re: incremental compilation via shared library

brent@jade.ssd.csd.harris.com (Brent Benson) said:
> I'm disappointed with the dynamic object file loader available in
> our SVR4 port. dlopen() will load a shared object file and
> resolve references to symbols in the original executable, but it
> will not resolve references to symbols in other shared objects
> that were loaded at run-time. Is this typical of SVR4 ports?
> What is the reason for this restriction?


Most probably because it does not keep a database of which other shared
objects were loaded and their symbol tables... Without having a
per-process area reserved to the dynamic loader where it can accumulate
state, it's hard to keep track of which objects have been dynamically
loaded and unloaded.


It can be done, but perhaps the SVR4 implementors decided that what they
provided was good enough for dynamically loading extensions to a main
program, which indeed largely is.


Multics does it, but then the Multics dynamic linker did keep state, and
in a privileged ring, and so on.
[For that matter, the OSF/1 loader keeps the full symbol table around all
the time, so dynamic linking comes essentially for free. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.