rethinking RTLD_NOW for loading plug-in modules

[Tom Yu]

I was doing some RTLD debugging traces on Solaris, and it appears that
for Solaris (and probably other dlopen()-supporting systems), loading
a shared object using dlopen() with the RTLD_NOW flag potentially
incurs the substantial performance penalty of immediately resolving
all symbol references in the opened object and all its dependencies.
If we combine this fact with the requirement for a shared object to
declare all of its dependencies (which is necessary in the case of
passing RTLD_GROUP to dlopen() or building modules using direct
binding), this likely means immediately resolving all symbol
references in libc.

Using the RTLD_NOW flag does have the advantage of forcing unresolved
symbol references to result in an immediate error condition, but I
don't know if that is worth the performance penalty of the immediate
binding of libc.  I think mostly what it buys us is insurance against
delayed failures when loading a plug-in module created by a developer
who did not check for unresolved symbols when building the plug-in
module.  For modules provided in our sources, we may be able to use
-zdefs (Solaris) linker option, or similar functionality on other
platforms.

Are people in favor of abandoning the RTLD_NOW requirement?

---Tom