Greetings Andy,
Thanks for the reminder. I think this should be included in 3.2.0,=20
which we are preparing now. Currently, we require an official bug=20
report before making any changes to CVS. Could you please fill in a=20
bug report on sourceforge so we can track it properly? Thanks.
Gabriele, this will require changing the configuration scripts again. =20
If I get stuck, could you please work your magic on them again?
My proposed solution is to remove the broken CHECK_SSL macro=20
entirely, and use AC_CHECK_HEADERS(openssl/ssl.h) which will define=20
the HAVE_OPENSSL_SSL_H macro, if it succeeds. This means that=20
users include specific paths to openssl/ssl.h the same way as they=20
do to any other header we use. It also means that the ssl code=20
can't be disabled, which is the current case, but appears not to be=20
the intention of the CHECK_SSL macro.
A trial patch is attached. Running autoconf 2.57 produced a=20
=2E/configure that worked on my system. (Andy, I'll mail the new =20
configure to you too, but don't want to post 800MB to this list!) I=20
think it will fail if openssl/ssl.h is found but either libssl or =20
libcrypto is missing. Does anyone know how to make it skip the test=20
for ssl.h if one of the others fails? Otherwise, we should add=20
HAVE_LIBCRYPTO and HAVE_LIBSSL to our #ifdefs...
Cheers,
Lachlan
On Thu, 16 Oct 2003 01:09, And...@wi... wrote:
> Not to harp, but I tried building the CVS a little bit ago and it
> still didn't set the HAVE_SSL_H stuff right, in that I had to go
> into the .h file and change the #define by hand. Sorry, I don't
> have the details, I can't get to that machine right now, but I just
> thought I'd mention it.
--=20
lh...@us...
ht://Dig developer DownUnder (http://www.htdig.org) |
