rethinking RTLD_NOW for loading plug-in modules

[Ken Raeburn]

On Apr 30, 2007, at 20:45, Tom Yu wrote:
> 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.

Do you wind up with more than one copy of libc mapped in?  Or does  
this part of the penalty, resolving the libc references, only happen  
with the first libc-using object opened with RTLD_NOW?

I guess I'd be okay with not using RTLD_NOW.  It does make the  
program less robust, but if the performance penalty is significant,  
perhaps it's a risk worth taking.

Ken