Jakob Bohm wrote:
1. The current README.WCE and code assumes that you link with one of two less free libraries (one is LGPL, the other requires reconfiguration of the target device/phone). I wrote my own more minimal library under the OpenSSL license to avoid them both. This obviously implied patching OpenSSL to use the new library rather than one of the two old ones.
Why does it mean patching OpenSSL ? wcecompat seems to be just providing some stdlib function not available by default on WCE, so isn't your library just an alternative implementation of those functions ? If not, then why ?
I suggest you put your lib on sourceforge or google code, and just provide the openssl patch. But I think your patch to openssl is much more likely to be accepted if you keep it as small as possible. If it's not small, maybe it's better, in a first step at least, to leave it together with the library on an external repository.
2. To simplify installation of my program, I prefer static linking of OpenSSL. This turned up a number of general (not WinCE specific) design issues in EVP and ASN code, resulting in massive bloat of programs that don't use all of OpenSSL. Basically, lots of .o files are pulled in by just-in-case calls (mostly XXX_free() functions), table-driven selection of which code to execute and other such bad practices. Using a number of ad-hoc patches I managed to cut down some of the overhead, but its not very clean or efficient yet.
Could you provide this as a separate patch, that you would call "openssl code reorganization to optimize for use on embedded platforms" ?
I think this discussion should continue on openssl-dev instead of -users. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
