Re: 7.9.2 solaris 2.5.1 compile (was Re: I am amazed...)
Date: Mon, 10 Dec 2001 17:30:08 +0100
Daniel Stenberg wrote:
> On Thu, 6 Dec 2001, Götz Babin-Ebell wrote:
> > > No. The client code should not use the library's config.h file, it has its
> > > own in src/config.h. Besides, the client code should not need socklen_t and
> > > in_addr_t. Why do your compiler require them?
> > if you configure with --enable-debug, src/main.c and src/urlglob.c
> > include lib/memdebug.h. And in lib/memdebug.h you need at least
> > socklen_t. If you set the #define socklen_t int from config.h in the
> > src/config.h, you don't need need the config.h...
> Well, the --enable-debug is a developers-only option and the include of
> lib/memdebug.h from the client code (that it activates) is a kludge in
> itself. We should make sure that it includes the proper includes within that
> file, we should not pollute the client source codes for other conditions.
As I mentioned: (at least I hope I mentioned it...) it was a quick
> > My changes in the interface of the library:
> > 1. curl_global_init() got an additional parameter: const char *param:
> > a comma seperated list of name=value-pairs,
> > for engine support I have added "CRYPTO_ENGINE=<engine>"
> Ugha. We don't want to change this. It would blow compatibility with almost
> every curl-using program out there. Why do we need to specify that already in
> the curl_global_init()? And why do we need a global variable for the
> 'crypto_engine' stuff? Why can't we set that option like we set other options
> with curl_easy_setopt()?
ENGINE_set_default() should be called early in the program.
Perhaps some additional curl_easy_setopt() options:
parameter: engine name
load an ENGINE and set it to the data structures...
like 1. but don't call ENGINE_set_default()
(for second session...)
parameter: pointer to an ENGINE
sets this as ENGINE
parameter: pointer to a memory area that will get the actual
> I'm sorry, but I'm not very familiar with this OpenSSL engine stuff so if my
> questions seem silly, please bear with me.
And I am no member of the OpenSSL core team and I had only a quick look
curl. So please bear with me...
> > 2. curl_global_init(): additional flag CURL_GLOBAL_SSL_XTRN:
> > signaling the ssl submodule that OpenSSL is initialized external
> > and no init is needed.
> Which then would be the complete opposite of the CURL_GLOBAL_SSL option and I
> can't see why CURL_GLOBAL_SSL_XTRN is needed then. Can't you just not use
> CURL_GLOBAL_SSL instead?
>From a glance in the code I belived you have to call Curl_SSL_init() to
use the SSL functionality.
But now I don't find the reference...
> > 2. Since curl_global_init() is called bevore the parameter list is
> > parsed,
> > I added an environmental variable (CURL_INIT_PARAMS).
> > Not good but a fast solution ;-)
> Eeeeh. That's just too icky. I don't like that.
> Taken all together, I haven't applied your patch yet. There's a few items
> that need to be sorted out first.
Some of these changes might be the result of a misunderstanding of
the curl interface on my side side...
Some of these changes were quick hacks...
-- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
- application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature