httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject 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)
Date Mon, 06 Aug 2012 21:36:20 GMT
On 05.08.2012 10:10, Kaspar Brand wrote:
> On 08.07.2012 10:30, Kaspar Brand wrote:
>> On 06.07.2012 14:41, wrote:
>>> Author: ben
>>> Date: Fri Jul  6 12:41:10 2012
>>> New Revision: 1358167
>>> URL:
>>> 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
>, 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.



View raw message