Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 8/8/2012 4:45 AM, Ben Laurie wrote: On Wed, Aug 8, 2012 at 2:47 AM, Guenter Knauf fua...@apache.org wrote: Am 08.08.2012 07:39, schrieb Kaspar Brand: On 06.08.2012 22:08, William A. Rowe Jr. wrote: On 8/5/2012 10:10 PM, Kaspar Brand wrote: On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Why not simply consume the installed openssl.pc? In this particular case we're talking about using an OpenSSL build directory, i.e. the generated openssl.pc is sitting in a temporary location in that build tree (and when used, would output incorrect includedir/libdir locations). probably a dumb question and I'm missing something, but: why is this necessary at all? Given someone wants to build/link against a development version of OpenSSL why should he ommit the last step of installing OpenSSL to a separate location? Time taken to iterate in development is an important determiner of productivity. Having to do an install for every change introduces significant delay. It also has a tendency to make debugging hard. I agree. An openssl 'make localinstall' could trivially create the lib, include trees consisting entirely of symlinks to the origin files in the same build tree, and create an appropriate openssl.pc file describing the link steps required to Rather than solving 'for the httpd case', this would allow you to build most any app or library depending upon openssl in a sensible way, in order to diagnose openssl's interoperation with any consumer. This really isn't the repository to solve openssl's contorted build issues.
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
Am 08.08.2012 07:39, schrieb Kaspar Brand: On 06.08.2012 22:08, William A. Rowe Jr. wrote: On 8/5/2012 10:10 PM, Kaspar Brand wrote: On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Why not simply consume the installed openssl.pc? In this particular case we're talking about using an OpenSSL build directory, i.e. the generated openssl.pc is sitting in a temporary location in that build tree (and when used, would output incorrect includedir/libdir locations). probably a dumb question and I'm missing something, but: why is this necessary at all? Given someone wants to build/link against a development version of OpenSSL why should he ommit the last step of installing OpenSSL to a separate location? Wouldnt everything work fine using --with-ssl= and building OpenSSL static-only + installing to a separate development location? Gün.
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On Wed, Aug 8, 2012 at 2:47 AM, Guenter Knauf fua...@apache.org wrote: Am 08.08.2012 07:39, schrieb Kaspar Brand: On 06.08.2012 22:08, William A. Rowe Jr. wrote: On 8/5/2012 10:10 PM, Kaspar Brand wrote: On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Why not simply consume the installed openssl.pc? In this particular case we're talking about using an OpenSSL build directory, i.e. the generated openssl.pc is sitting in a temporary location in that build tree (and when used, would output incorrect includedir/libdir locations). probably a dumb question and I'm missing something, but: why is this necessary at all? Given someone wants to build/link against a development version of OpenSSL why should he ommit the last step of installing OpenSSL to a separate location? Time taken to iterate in development is an important determiner of productivity. Having to do an install for every change introduces significant delay. It also has a tendency to make debugging hard. Wouldnt everything work fine using --with-ssl= and building OpenSSL static-only + installing to a separate development location? Gün.
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 06.08.2012 22:08, William A. Rowe Jr. wrote: On 8/5/2012 10:10 PM, Kaspar Brand wrote: On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Why not simply consume the installed openssl.pc? In this particular case we're talking about using an OpenSSL build directory, i.e. the generated openssl.pc is sitting in a temporary location in that build tree (and when used, would output incorrect includedir/libdir locations). Kaspar
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 8/5/2012 10:10 PM, Kaspar Brand wrote: On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Why not simply consume the installed openssl.pc?
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 05.08.2012 10:10, Kaspar Brand wrote: On 08.07.2012 10:30, Kaspar Brand wrote: On 06.07.2012 14:41, b...@apache.org wrote: Author: ben Date: Fri Jul 6 12:41:10 2012 New Revision: 1358167 URL: http://svn.apache.org/viewvc?rev=1358167view=rev Log: Work correctly with a development version of OpenSSL. I suspect something similar is needed when there are two OpenSSL installations, one in a default location. I had another look at this, since it has been proposed for backporting to 2.4 in the meantime, and still think the following is true: If I'm understanding correctly, then this patch tries to support building against an OpenSSL source tree (or perhaps a build directory where only make libs has been executed)? That is my understanding as well. (should have read make build_libs instead) It's a useful enhancement if mod_ssl can be linked with a specific OpenSSL version in a non-default location, but the current approach has at least one problem, AFAICT: it will only work if the directory pointed to by --with-ssl does not include shared libraries for OpenSSL (by default, OpenSSL only builds libssl.a and libcrypto.a, so the issue might not be obvious at first sight). Why wouldn't it work with shared libs? Because they usually have dependencies themselves that are ignored? I would suggest to use a separate configure argument to support this build option, e.g. --with-ssl-srcdir. We could, but I think if it would be easy to just add the logic to with-ssl to also work with a src directory it would be easier to use. I have no strong opinion on this though. I gave it a try, see the attached work-in-progress patch. While we're at it, I think we should also fix a flaw in the handling of the --with-ssl argument: in http://svn.apache.org/viewvc?view=revisionrevision=730926, acinclude.m4 was modified to always give pkg-config precedence over any argument specified through --with-ssl. While the rationale for this change becomes clear from the commit log, I consider it an unfortunate side effect that pkg-config always trumps any --with-ssl directory argument. My suggestion would be to handle OpenSSL paths in configure arguments like this, instead: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) 2) use --with-ssl for linking against an installed version of OpenSSL 3) use pkg-config to locate OpenSSL Does that sound like a reasonable proposal? Comments welcome, and test feedback would be much appreciated (remember to run buildconf after applying the patch to acinclude.m4, and before calling configure). I do like the idea to give with-ssl priority over pkgconfig. If a user chooses the ssl directory explicitly that should not be overwritten by pkgconfig. Of course one can still use pkgconfig info in the chosen directory to find dependency libs etc. Whether 1) and 2) needs to be a separate priority or simply using the same switch and auto-detect whether it is an installation directory or only a build directory is undecided to me. Regards, Rainer
Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 08.07.2012 10:30, Kaspar Brand wrote: On 06.07.2012 14:41, b...@apache.org wrote: Author: ben Date: Fri Jul 6 12:41:10 2012 New Revision: 1358167 URL: http://svn.apache.org/viewvc?rev=1358167view=rev Log: Work correctly with a development version of OpenSSL. I suspect something similar is needed when there are two OpenSSL installations, one in a default location. I had another look at this, since it has been proposed for backporting to 2.4 in the meantime, and still think the following is true: If I'm understanding correctly, then this patch tries to support building against an OpenSSL source tree (or perhaps a build directory where only make libs has been executed)? (should have read make build_libs instead) It's a useful enhancement if mod_ssl can be linked with a specific OpenSSL version in a non-default location, but the current approach has at least one problem, AFAICT: it will only work if the directory pointed to by --with-ssl does not include shared libraries for OpenSSL (by default, OpenSSL only builds libssl.a and libcrypto.a, so the issue might not be obvious at first sight). I would suggest to use a separate configure argument to support this build option, e.g. --with-ssl-srcdir. I gave it a try, see the attached work-in-progress patch. While we're at it, I think we should also fix a flaw in the handling of the --with-ssl argument: in http://svn.apache.org/viewvc?view=revisionrevision=730926, acinclude.m4 was modified to always give pkg-config precedence over any argument specified through --with-ssl. While the rationale for this change becomes clear from the commit log, I consider it an unfortunate side effect that pkg-config always trumps any --with-ssl directory argument. My suggestion would be to handle OpenSSL paths in configure arguments like this, instead: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) 2) use --with-ssl for linking against an installed version of OpenSSL 3) use pkg-config to locate OpenSSL Does that sound like a reasonable proposal? Comments welcome, and test feedback would be much appreciated (remember to run buildconf after applying the patch to acinclude.m4, and before calling configure). Kaspar Index: acinclude.m4 === --- acinclude.m4(revision 1369535) +++ acinclude.m4(working copy) @@ -467,86 +467,97 @@ dnl dnl APACHE_CHECK_OPENSSL dnl -dnl Configure for OpenSSL, giving preference to -dnl --with-ssl=path if it was specified. +dnl Configure for OpenSSL, giving preference to the following options: +dnl 1) --with-ssl-builddir=path, for linking against static libraries +dnlin an OpenSSL build directory where at least make build_libs +dnlhas been executed +dnl 2) --with-ssl=path, pointing to a path where an installed version +dnlof OpenSSL can be found +dnl 3) the path as determined by pkg-config dnl AC_DEFUN(APACHE_CHECK_OPENSSL,[ - AC_CACHE_CHECK([for OpenSSL], [ac_cv_openssl], [ + AC_CACHE_VAL([ac_cv_openssl], [ dnl initialise the variables we use ac_cv_openssl=no -ap_openssl_found= ap_openssl_base= -ap_openssl_libs= +saved_CPPFLAGS=$CPPFLAGS +SSL_LIBS= -dnl Determine the OpenSSL base directory, if any -AC_MSG_CHECKING([for user-provided OpenSSL base directory]) -AC_ARG_WITH(ssl, APACHE_HELP_STRING(--with-ssl=DIR,OpenSSL base directory), [ - dnl If --with-ssl specifies a directory, we use that directory - if test x$withval != xyes -a x$withval != x; then -dnl This ensures $withval is actually a directory and that it is absolute +AC_MSG_NOTICE([checking for OpenSSL...]) + +dnl Allow linking against static libraries from an OpenSSL build directory +AC_MSG_CHECKING([for user-provided OpenSSL build directory with static libraries]) +AC_ARG_WITH(ssl-builddir, APACHE_HELP_STRING(--with-ssl-builddir=DIR,OpenSSL build directory with static libraries to link with), [ + if test x$withval != xyes -a -d $withval; then +dnl This ensures $withval is actually a directory +dnl and that it is absolute ap_openssl_base=`cd $withval ; pwd` +if test x$ap_openssl_base != x; then + AC_MSG_RESULT($ap_openssl_base) + CPPFLAGS=-I$ap_openssl_base/include $CPPFLAGS + INCLUDES=-I$ap_openssl_base/include $INCLUDES + if test x$enable_ssl = xstatic; then +APR_ADDTO(LIBS, [$ap_openssl_base/libssl.a $ap_openssl_base/libcrypto.a]) + else +LDFLAGS=-L$ap_openssl_base -Wl,-L$ap_openssl_base $LDFLAGS +dnl force the linker to use libssl.a and libcrypto.a (but only +dnl these, i.e. make sure that we are switching back to dynamic +dnl mode afterwards - from ld(1): affects library searching +dnl for -l options which follow it) +APR_ADDTO(SSL_LIBS,
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 05.08.2012 10:10, Kaspar Brand wrote: test feedback would be much appreciated (remember to run buildconf after applying the patch to acinclude.m4, and before calling configure). The patch attached to the previous message was missing an important line, unfortunately (sorry to anybody who already played with it). Apply the one below on top of mod_ssl-configure-options.patch, and things should work properly. Kaspar --- acinclude.m4.orig +++ acinclude.m4 @@ -574,6 +574,7 @@ ap_apr_libs=`$apr_config --libs` APR_ADDTO(SSL_LIBS, [$ap_apr_libs]) APR_ADDTO(LIBS, [-lssl -lcrypto $ap_apr_libs]) + APACHE_SUBST(SSL_LIBS) dnl Run library and function checks liberrors=
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
Hi Kaspar, Am 05.08.2012 10:10, schrieb Kaspar Brand: My suggestion would be to handle OpenSSL paths in configure arguments like this, instead: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... just a thought ... Gün.
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Kaspar
Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c
On 06.07.2012 14:41, b...@apache.org wrote: Author: ben Date: Fri Jul 6 12:41:10 2012 New Revision: 1358167 URL: http://svn.apache.org/viewvc?rev=1358167view=rev Log: Work correctly with a development version of OpenSSL. I suspect something similar is needed when there are two OpenSSL installations, one in a default location. Modified: httpd/httpd/trunk/acinclude.m4 httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Modified: httpd/httpd/trunk/acinclude.m4 URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/acinclude.m4?rev=1358167r1=1358166r2=1358167view=diff == --- httpd/httpd/trunk/acinclude.m4 (original) +++ httpd/httpd/trunk/acinclude.m4 Fri Jul 6 12:41:10 2012 [...] +dnl See if we've been given a development OpenSSL (lib does not exist) +if test ! -d $ap_openssl_base/lib; then + AC_MSG_WARN([Using development version of OpenSSL]) + dnl we need to prepend the directories to override the system version + CPPFLAGS=-I$ap_openssl_base/include $CPPFLAGS + INCLUDES=-I$ap_openssl_base/include $INCLUDES + LDFLAGS=-L$ap_openssl_base $LDFLAGS + dnl naughty, but easier than the alternatives + saved_LDFLAGS=$LDFLAGS + SSL_LIBS=-L$ap_openssl_base +else The --with-ssl argument to configure expects a path to (the base of) an installed version of OpenSSL. If I'm understanding correctly, then this patch tries to support building against an OpenSSL source tree (or perhaps a build directory where only make libs has been executed)? If that assumption is correct, then I would suggest to use a separate configure argument to support this build option, e.g. --with-ssl-srcdir. Kaspar
