Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Date: Sun, 24 Sep 2017 22:49:24 +0200 (CEST)
From: "Jens Schleusener" <Jens.Schleusener@t-online.de>
To: users@httpd.apache.org
Message-ID: <alpine.LSU.2.20.1709242211340.23484@schiller.site>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Subject: [users@httpd] mod_ssl: problem using a self-compiled OpenSSL installation on a
 64-bit Linux system
archived-at: Sun, 24 Sep 2017 20:49:37 -0000

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?

Regards

Jens

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org