Before this goes in, I'm going to take this opportunity to raise a question that I've documented on the wiki (which came up in a discussion off-list):
http://wiki.openssl.org/index.php/Unit_Testing#How_to_Manage_Private_Symbols Why do any of the symbols need to be private? Is that degree of encapsulation necessary, and does it really discourage irresponsible clients? The source code is open, so people can always build their own copy and depend on internals if they really want to, and the default UNIX/Linux/OS X build (i.e. ./configure && make && make test) doesn't lock down internal symbols. Have dependencies on internal APIs ever been a problem in practice? I'm not saying I feel strongly either way, but it seems that clients should be clear that the public API is what's available in openssl/include, and shouldn't depend on anything else. I just don't understand what making symbols private buys anyone in the context of OpenSSL, in light of how it appears to complicate the ability to unit test. Not trying to be argumentative, I just want to understand the rationale. I'll work with whatever environment I have to. Mike On Sat, Jun 7, 2014 at 7:38 AM, Kurt Roeckx via RT <r...@openssl.org> wrote: > On Thu, Jun 05, 2014 at 11:59:30PM +0200, Matt Caswell via RT wrote: >> On Thu Jun 05 23:42:31 2014, k...@roeckx.be wrote: >> > >> > > We are likely to see >> > > a lot more like this as Mike's test team get going. In unit testing >> > its "okay" >> > > to access internal symbols. >> > >> > But then you shouldn't link to the shared library. The static >> > library probably works. >> >> Any chance you can knock together a patch to do this and test it with your >> script? > > Github pull request #125. > > > Kurt > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
