rethinking RTLD_NOW for loading plug-in modules

[Tom Yu]

>>>>> "Ken" == Ken Raeburn <raeburn at MIT.EDU> writes:

Ken> I just want to get a clearer picture of what the penalty is, given
Ken> that loading and using a module with undefined symbols may have a
Ken> penalty of the program crashing.

I suspect that one advantage is that calling dlopen() using RTLD_NOW
on a shared object having undefined symbols will simply fail the
dlopen() call, rather than crashing the program.  Having code in the
shared object call through an unresolved reference causes the RTLD to
kill the process under Solaris, and probably elsewhere as well.

Of course, we should always build our provided plug-in modules using
"-zdefs" or equivalent, so they cannot have unresolved references.
I'm not sure whether we want to use RTLD_NOW as a defense against
third-party modules having unresolved references.  It ends up being a
performance tradeoff against other people's readily avoidable errors.

On Solaris at least, "ldd -r" tells you if there are unresolved lazy
references in a shared object.  I would hope that other platforms have
equivalent functionality.

---Tom