Re: incremental compilation via shared library

brent@jade.ssd.csd.harris.com (Brent Benson) writes:
>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?


It seems like a common restriction. I'm not sure why, but it's possible
that it's because dlopen and friends were only implemented for doing
shared libraries, and weren't implemented in a very general way. I've
also found that even when you push at the corners of supported
functionality, there are quite obvious bugs (for example, on
SVR4.2/UnixWare/Univel doing a dlopen/dlsym from within a module that is
itself dlopened causes a SIGSEGV within dlsym, at least in the very simple
case I tried it in).


You may want to look at dld, which is a dynamic linker which allows
linking and unlinking of object files, and allows you to manipulate the
symbol table in interesting ways.


It only copes with a.out-type executable and object files, but it works on
a variety of systems from SunOS to Linux.


dld is under the FSF GPL, and the latest version I've seen is 3.2.2.


J
--

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