> [mailto:[EMAIL PROTECTED]]On Behalf Of Lawrence Greenfield
...
> $ /usr/ccs/bin/ld -G -h libdigestmd5.so.0 -o
> .libs/libdigestmd5.so.0.0.17 digestmd5.lo -L/usr/local/lib
> -L/usr/local/src/db/db-3.1.17/build_unix
> -L/usr/local/src/OpenSSL/openssl-0.9.5a/lib -lcrypto -lsocket
> -lnsl -lc -R/usr/local/lib
>
> 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
====================================================================
Ready-to-Run Software, Inc.
Software Porting Specialists.
*****************************
email: [EMAIL PROTECTED] Gary Feldman
fax : 1-978-692-5401 Ready-to-Run Software, Inc.
voice: 1-978-251-5431 11 School Street
www : http://www.rtr.com North Chelmsford, MA 01863
USA
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
