bsikora has been investigating Solaris test matrix results and he hit the wall with Solaris 10/11 Intel 32bit with what appeared to be just another lib loading issue similar to JWS-184.

Cannot load modules/mod_ssl.so into server: ld.so.1: httpd: fatal: libssl.so.0.9.8: open failed: No such file or directory

Carrying it further, I tried to dig into with which libs is the mod_ssl dynamic object linked in 3.0.1-ER1 and the result is that while 64bit Intel and SPARC are linked correctly, the 32bit Intel actually links to an older OpenSSL version unsupported in JBoss.

Problem

jws-httpd-3.0.1-ER1-sun10.x86_64.zip

ldd ./64/jws-3.0/lib64/httpd/modules/mod_ssl.so
    libssl.so.10 =>       /tmp/64/jws-3.0/lib64/httpd/modules/../../libssl.so.10
    libcrypto.so.10 =>    /tmp/64/jws-3.0/lib64/httpd/modules/../../libcrypto.so.10

jws-httpd-3.0.1-ER1-sun10.i386.zip

ldd ./32/jws-3.0/lib/httpd/modules/mod_ssl.so
    libssl.so.0.9.8 =>    (file not found)
    libcrypto.so.0.9.8 => (file not found)

Action

We need to make sure the CR1 Intel 32bit build links the correct OpenSSL lib. On the QE side, this shouldn't have passed the preliminary tests. Some of the environments were poisoned with having /opt/csw/lib/ on LD_LIBRARY_PATH,

libssl.so.0.9.8 =>       /opt/csw/lib//libssl.so.0.9.8
libcrypto.so.0.9.8 =>    /opt/csw/lib//libcrypto.so.0.9.8

, which results in a nice and smooth Apache HTTP Server start without any errors:

AH00163: Apache/2.4.6 (Unix) mod_auth_kerb/5.4 OpenSSL/0.9.8zb mod_cluster/1.3.1.Final configured -- resuming normal operations

, with wrong OpenSSL/0.9.8zb loaded. The Intel 32bit test setups are being updated at the moment.