httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: [users@httpd] mod_ssl: problem using a self-compiled OpenSSL installation on a 64-bit Linux system
Date Sun, 24 Sep 2017 21:24:11 GMT
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" 
> output extract
> => /lib64/
> => /lib64/
> 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" showed now the self-compiled 
> openssl libs in use
> => /usr/local/sc/lib64/
> => /usr/local/sc/lib64/
> and the warning in the error_log also disappeared.
> Alternatively I could probably add generally /usr/local/sc/lib64 into 
> /etc/ 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 


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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message