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=1358167&view=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=revision&revision=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

Reply via email to