httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <>
Subject [PATCH] openssl configuration (v2)
Date Tue, 04 Mar 2003 23:43:03 GMT
Hi all,

Thanks to those who replied to my earlier post on this subject,
especially Madhu. Here's the next incarnation of the patch based on that
feedback and some ferretting of my own.

Patch notes;

- This now probes for sslc.h to distinguish between OpenSSL and SSL-C.
  - Existing version checking only made sense for OpenSSL so is now only
    done for OpenSSL.
  - The version "error" is now just a warning.
  - HAVE_OPENSSL and HAVE_SSLC are set up from these tests so that
    modules/ssl/ code can be clearer and less ambiguous.

- Libraries are now checked by AC_CHECK_LIB instead of AC_TRY_LINK as in
  my previous patch. This lets autoconf/automake deal with adding the
  appropriate "-lssl -lcrypto" linker flags, so this should be a little
  more portable.

- inclusion of openssl or ssl-c headers now takes place in
  ssl_toolkit_compat.h instead of mod_ssl.h. This results in cleaner
  handling of the [HAVE|NO]_SSL_X509V3_H stuff for SSL-C (and which
  isn't relevant for OpenSSL at all). Also, paths are now correct for
  headers, so an installed version of OpenSSL or SSL-C will usable as-is
  without needing any -I flags generated from the configure script.

Questions for apache gurus/code-reviewers;

- AC_CHECK_HEADERS() appears difficult to coax into accepting additional
  include paths, so if "--with-ssl=<path>" is specified there appears no
  obvious way to have AC_CHECK_HEADERS() pick up those headers in
  (particularly if versions exist in system locations too and we want
  autoconf's tests to find the <path> versions in preference to any
  auto-detectable ones). I've left some comments in the acinclude.m4
  changes about this. For now, I've made do with adding "-I<...>" to
  CFLAGS prior to AC_TRY_COMPILE, but I'm sure autoconf intended some
  other way of handling this. For one thing, is "-I" actually portable
  anyway? The existing code depends utterly on it but it would be nice
  to do away with it altogether.

- My changes use autoconf tests for openssl/ssl-c headers and libraries
  (existing code just looks for files but doesn't actually try to use
  them). As a result, linker flags like -ldl, -lsocket, -lnsl, -ldld,
  etc are needed in advance of these tests. I've added the obvious ones
  I know about so that this patch can be tested as-is, but ideally
  Apache's builtin tests (which are obviously OK because Apache links
  fine) should occur before the AC_CHECK_LIB()s for "ssl" and "crypto".
  See "Step 3" of my changes to acinclude.m4.

- The adjustments made to LDFLAGS at the end of the testing has been
  written to try and match the existing stuff, but I don't confess to
  know what the significance of $ap_platform_runtime_link_flag is so I'm
  working blind there.

- I'm tagging "-DHAVE_OPENSSL" or "-DHAVE_SSLC" directly onto CFLAGS
  rather than using anything like AC_DEFINE because the latter
  possibility would require HAVE_OPENSSL and HAVE_SSLC to be stubbed
  into an appropriate "" file. If you prefer not to have
  such stuff polluting CFLAGS then please suggest an appropriate ".in"
  file for me to hook into.

Note that (I think) the problems of relying on syntax like "-I", "-L",
etc all apply to the existing code anyway, so they're more questions of
style than whether my changes will work. The only things I can think of
that my changes my break are that I've dumped the builtin paths for
searching for headers and libraries and instead let autoconf probes
(combined with --with-ssl=<path>) find whatever they find. In other
words, perhaps some people might have been relying on the unconventional
anti-autoconf nature of the existing checks that my changes remove?

Any/all feedback most welcome.


Geoff Thorpe

View raw message