On 21-09-2010 18:48, Jean-Marc Desperrier wrote:
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 ?
The "os dependency" files in openssl assume specifics of either
wcecompat or the other restricted library, I have simply added
alternative cases for my simpler cedummy library.
My cedummy library provides much fewer libc function replacements than
wcecompat, relying instead on windows CE's standard libc and adding
just a few missing functions (such as gmtime()).
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.
Yes, it needs trimming and cleanup to keep the patch minimal, which is
why I have not posted it yet. The initial home of the library will
probably be on one of our own sites.
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" ?
This part is actually the largest part (in kilobytes) of my private
patch. This is not as much about embedded platforms as it is about
static linking to openssl (on any platform where a recent openssl shared
library is not included by default, including desktop systems).
I think this discussion should continue on openssl-dev instead of -users.
Maybe it should, I am not subscribed there, as the list description
clearly dissuaded library users like myself from using that list. But
maybe.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
