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 LDFLAGSOk, but that seems not sufficient since the following "ldd mod_ssl.so" output extractlibssl.so.1.0.0 => /lib64/libssl.so.1.0.0 libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0showed 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 uselibssl.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_LDADDinstead 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: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|