While it is possible to make a Valgrind clean (as in memory leaks)
executable, that loads OpenSSL DSO/DLLs exactly once during the
executable lifetime.
I'm not sure it has ever been a feasible goal to make OpenSSL DSO/DLLs
able to be unloaded (with the aim of subsequently loading). Let alone a
goal that this function of dynamic-linking is claimed to be supported by
OpenSSL in its documentation.
I won't dispute it is a worthy goal of any DSO to be compliant with use
of dlunload() but I see wider issues needing resolution at the same
time. For a start doesn't there need to be a mechanism where a
superior-executable can ask the DSO if it is ready to unload, maybe
there are hooks in dlunload() to inquire on this.
This ignores the nice to have features of:
* Exposed reference counters for dlopen to the DSO itself
* Ability for a DSO to say, you can never unload me
Maybe these problem are already solved on the platforms you are working
with (FreeBSD / OpenSolaris) and I'd certainly like to hear about that.
As glibc/linux takes a somewhat different stance.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
