Am 24.09.2017 um 22:49 schrieb Jens Schleusener:
Hi,
if I formerly compiled the Apache httpd server myself using an also
self-compiled OpenSSL installation for building "mod_ssl" as a shared
module I added only the configure option "--with-ssl" to specify the
according OpenSSL installation directory (if I remember correctly).
Now on a 64-bit Linux system it seems no longer to work. OpenSSL was
installed by using the configure option "--prefix" say into a directory
named /usr/local/sc (sc=self-compiled) so I added accordingly the httpd
configure option "--with-ssl=/usr/local/sc". But looking in the output
of the configure run and the configure script itself (below "Check
whether --with-ssl was given") I had the impression that the script
checks only for the condition
-f "${ap_openssl_base}/lib/pkgconfig/openssl.pc"
In my example case that would be result into a check for the existence
of the pkg-config file /usr/local/sc/lib/pkgconfig/openssl.pc but the
self-compiled openssl libs (1.0.2l) were installed on my 64-bit system
under /usr/local/sc/lib64 so the searched file exists instead under
/usr/local/sc/lib64/pkgconfig/openssl.pc.
So I changed just for testing in the configure script within the four
openssl relevant lines (line numbers 26048/26049 and 28901/28902)
the string /lib/pkgconfig into /lib64/pkgconfig and thereafter the
configure output now mentioned amongst others
adding "-I/usr/local/sc/include" to CPPFLAGS
adding "-L/usr/local/sc/lib64" to LDFLAGS
Ok, but that seems not sufficient since the following "ldd mod_ssl.so"
output extract
libssl.so.1.0.0 => /lib64/libssl.so.1.0.0
libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0
showed that nevertheless the "default" openssl libs (1.0.2j) of the
distribution seems to be used. Additionally after setting
"LogLevel ssl:info" in the httpd.conf and starting the httpd daemon
I found in the error_log file the corresponding lines
[ssl:info] [xxx] AH01876: mod_ssl/2.4.27 compiled against Server:
Apache/2.4.27, Library: OpenSSL/1.0.2l
[ssl:warn] [xxx] AH01882: Init: this version of mod_ssl was compiled
against a newer library (OpenSSL 1.0.2l 25 May 2017,
version currently loaded is OpenSSL 1.0.2j-fips 26 Sep 2016) -
may result in undefined or erroneous behavior
So I set before the configure run additionally the environment variable
LDFLAGS="-Wl,-rpath=/usr/local/sc/lib64"
and that seems to help: A "ldd mod_ssl.so" showed now the self-compiled
openssl libs in use
libssl.so.1.0.0 => /usr/local/sc/lib64/libssl.so.1.0.0
libcrypto.so.1.0.0 => /usr/local/sc/lib64/libcrypto.so.1.0.0
and the warning in the error_log also disappeared.
Alternatively I could probably add generally /usr/local/sc/lib64 into
/etc/ld.so.conf but to avoid incompatibility conflicts I don't want all
the other self-compiled libs in /usr/local/sc/lib64 used by default
(maybe I could put /usr/local/sc/lib64 as last entry).
Maybe on 64-bit systems a loop at least over "lib" and "lib64" should be
done in the according configure script checks.
Is that all correct or are there other mechanisms or better solutions
existent in order to handle the described problem?
Not a full solution but concerning the rpath flag you can use the more
precise
MOD_SSL_LDADD
instead of LDFLAGS. The latter will be used for any linking,
MOD_SSL_LDADD only for mod_ssl linking. If you compile "ab" also with
ssl support, you might also want to set ab_LDADD and if you compile apr
crypto, you can use LDADD_crypto_openssl.
For the lib64 part a workaround might by setting PKG_CONFIG_PATH before
running configure.
But you are right, it would be better if our configure script would also
check lib64 on appropriate platforms.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
