> > [mailto:[EMAIL PROTECTED]]On Behalf Of Lawrence Greenfield
> > this solves the work problem, but does it in a very inefficient
> > manner. At least on Solaris, this will create a new, process-private,
> > copy of libcrypto.a for every process that dynamical loads
> > libdigestmd5.so.
> Am I missing something here? I would have thought that linking
> to create a
> new .so file, using an existing .a file as one of the inputs
> would copy all
> of the relevant units into the .so file, so that ever process that
> dynamically loads the .so file would share the .so file, and thus
> share the
> included libcrypto.a. Is there something that prevents the
> libcrypto.a code
> from being shared in this context? (Granted, it's not being
> shared as much
> as a fully shared libcrypto.so would be.)
>
> Gary
You're both correct. Since libcrypto.a was not compiled as PIC, it cannot be
shared very much. The library will have static absolute address references
that will be relocated at runtime, forcing page copies for every relocated
reference.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
