On Sun, Aug 12, 2012 at 5:23 PM, Kaspar Brand <httpd-dev.2...@velox.ch> wrote:
> 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)
I haven't had time to retest it, but I think the problem with this
approach is that the default version of OpenSSL gets included first if
anything else uses /usr/local/{include,lib}. IIRC, this was the basis
of all my problems.
>
> 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
