On Thu, Dec 09, 2004 at 10:35:36AM +0100, Daniel Stenberg wrote:
> Hi peeps
>
> Below is a single mail taken from a private discussion between me and Dan
> Fandrich. I'm forwarding it here with his permission.
>
> I feel a bit swamped right now so while I consider the remarks below valid,
> I don't think I'll have much time or energy to clean up these matters right
> now. Of course I'll accept patches that do the work
>
> Dan, you could resend your patch to the list to let people see what we
> discuss.

Sure, I've attached the original patch. Here's the original message:

>> I found a problem in that the --without-random configure option didn't
>> work as expected; it produced a file called "no". I've fixed that in the
>> attached patch. I also moved the random number stuff into the --with-ssl
>> block so it is skipped if the user specifies --without-ssl. This
>> makes cross-compiles a bit easier since configure otherwise aborts if no
>> random file is specified on the command line on a cross compile. A better
>> fix would be to skip the random file check if the configure tests don't
>> find the necessary SSL files (instead of relying on --without-ssl), but
>> the compile time check for SSL support is complicated based on lots of
>> header file, and I didn't want to copy that complication into configure
>> as well.

The second half of that paragraph relates to the underlying SSL
configuration problem, in that the determination of whether SSL is going
to be supported or not is made in setup.h, when it needs to be done in
configure. Right now, a nearly duplicate test is performed in both places
and configure can't rely on it because the setup.h test may change out of
lock-step.

The source code needs to know two main things: whether SSL is going to
be used or not (USE_SSLEAY) and second, whether the header files are in
their own openssl/ directory or not (USE_OPENSSL). HAVE_OPENSSL_ENGINE_H
is also handled specially.

Now that I've thought this through, it looks like fixing it is actually
going to be pretty trivial. All that really needs to be done is to move
setting USE_SSLEAY and USE_OPENSSL from setup.h into configure. Some
of the hard-coded architecture-specific config-*.h will probably have to
change as well, but it looks like this will be pretty nondisruptive.

Any comments? I'll send out a new patch that does this soon.

>>> Dan

> ---------- Forwarded message ----------
> Date: Wed, 8 Dec 2004 16:59:49 -0800
> From: Dan Fandrich <dfandrich_at_intrinsyc.com>
> To: Daniel Stenberg <daniel_at_haxx.se>
> Subject: Re: curl random file and configure
>
> On Thu, Dec 09, 2004 at 12:00:07AM +0100, Daniel Stenberg wrote:
> >That complexity is in fact already in the configure script. The
> >OPENSSL_ENABLED variable gets set to 1 when the script considers there's a
> >valid OpenSSL enabled. You could use that variable as a pre-condition for
> >the
> >random file check. Won't that be better?
>
> That would be better, but I'm a bit confused as to the relationships between
> all the (very closely related) variables. In configure there are defined:
> OPT_SSL
> HAVECRYPTO
> OPENSSL_ENABLED
> in setup.h are defined:
> USE_SSLEAY
> USE_OPENSSL
> plus there are a bunch in config.h.in like:
> HAVE_LIBSSL
> HAVE_LIBCRYPTO
> and all the header file ones. Can these be unified? Perhaps configure
> should export USE_SSLEAY and USE_OPENSSL to replace the internal
> OPENSSL_ENABLED, which would clean up setup.h, too.
>
> >I'll wait with applying to let you either move the check and post a new
> >patch,
> >or just tell me things are fine as they are when your current patch is
> >applied.
>
> Feel free to cc: this to the libcurl mailing list if you want wider
> exposure.
>
> >>>Dan