httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <httpd-dev.2...@velox.ch>
Subject Re: Linking mod_ssl with a specific OpenSSL version
Date Sun, 12 Aug 2012 16:23:00 GMT
On 10.08.2012 01:55, William A. Rowe Jr. wrote:
> 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

Specifically, that "lib" subdirectory would have to be populated like so:

lib
|-- engines
|   |-- lib4758cca.so
|   |-- ...
|   `-- libubsec.so
|-- pkgconfig
|   |-- libcrypto.pc
|   |-- libssl.pc
|   `-- openssl.pc
|-- libcrypto.a
|-- libcrypto.so -> libcrypto.so.1.0.0
|-- libcrypto.so.1.0.0
|-- libssl.a
|-- libssl.so -> libssl.so.1.0.0
`-- libssl.so.1.0.0

(If pkg-config is in $PATH, but lib/pkgconfig/openssl.pc is missing,
then httpd's configure will pick the "default" installation of OpenSSL,
and ignore the directory specified through --with-ssl.)

> 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.

I tend to agree, and would be in favor of reverting r1358167. As long as
OpenSSL doesn't provide a Makefile target for creating the "lib"
subdirectory in the build tree, a workaround is to call configure with
suitable {CPP,LD}FLAGS, i.e.

  CPPFLAGS=-I${openssl_build_dir}/include \
  LDFLAGS=-L${openssl_build_dir} \
  ./configure ...

(when using the shared libssl/libcrypto libraries, adding
"-Wl,-R${openssl_build_dir}" or similar to LDFLAGS might make sense)

One problem with the current version of acinclude.m4 I noticed in the
meantime is that on OS X, the test in line 503
(https://svn.apache.org/viewvc/httpd/httpd/trunk/acinclude.m4?view=markup&pathrev=1358167#l503)
is true whenever --with-ssl is missing from the configure arguments (OS
X doesn't have /lib). configure will then add bogus "-L" strings to
SSL_LIBS and EXTRA_LDFLAGS in build/config_vars.mk... and this breaks
the link commands for the whole tree ("libtool: link: require no space
between `-L' and `-o'").

Kaspar

Mime
View raw message