On Dec 18, 2008, at 5:47 AM, xPostings wrote:
compiled zlib: ./configure make make install
What's your prefix here? It'd probably default to /usr/local
compiled openssl 0.9.8i: ./config no-zlib shared make make install
Again, what's the prefix? And, specifying 'shared' will build the *.so libraries which are then picked up by the Apache build system.
compiled apache httpd: ./buildconf ./configure --prefix=/usr/local/apache2.2.11 \ --enable-static-support \ --with-mpm=worker \ --enable-mods-shared=all \ --enable-so \ --enable-deflate=static \ --with-z=/usr/local/lib \
Usually, you point to the top of the zlib installation which would be / usr/local, under which the compiler finds the include/headers and the linker finds the lib/libraries.
--enable-ssl=static \ --with-ssl=/usr/local/ssl \
This must match your prefix above, or the default.
--enable-rewrite=static \ --enable-auth-basic=static \ --enable-authn-file=static \ --enable-authz-user=static \ --enable-authz-groupfile=static \ --enable-authz-host=static \ --enable-expires=static \ --enable-headers=staticIf I look to the depencies with ldd there is a dynamically linked libz and libssl:linux-gate.so.1 => (0xffffe000)libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7eb9000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d7e000)
That's your system installation of openssl 0.9.8*. Two things may have happened:
1) You linked against the .so shared libraries in your installation, but at runtime you're picking up the system copy. It seems that embedding the hard path to the shared libraries in the calling binary doesn't work too well on Linnicks. This can be remedied by adding / usr/local/ssl/lib (or whatever, see the discussion on prefix above) to the LD_LIBRARY_PATH environment variable when you start Apache. This can be done in the script that starts the server, or on the command line for testing.
2) The System openssl was found in favor of yours when configuring. This should not happen. Study your ./configure output where it tries to find the proper openssl library and see what exactly happens there.
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d59000)libaprutil-1.so.0 => /usr/local/apache2.2.11/lib/ libaprutil-1.so.0 (0xb7d3d000) libexpat.so.0 => /usr/local/apache2.2.11/lib/libexpat.so.0 (0xb7d21000) libapr-1.so.0 => /usr/local/apache2.2.11/lib/libapr-1.so.0 (0xb7cfc000)librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7cf3000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7cc4000)libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7cb2000)libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7cae000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b7d000) libz.so.1 => /usr/lib/libz.so.1 (0xb7b69000)
Again, that's the system copy. Same story, plus it may not have found yours because your parameter was off. Again, see your ./configure output.
/lib/ld-linux.so.2 (0xb7efe000)What's going wrong? libssl and libz shouldn't be linked dynamically. With httpd 2.2.3 and the same configuration I haven't had these problems. ldd from the old 2.2.3 shows following depencies:linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7edf000)libaprutil-1.so.0 => /usr/local/apache2.2.3/lib/ libaprutil-1.so.0 (0xb7ec9000) libexpat.so.0 => /usr/local/apache2.2.3/lib/libexpat.so.0 (0xb7eac000) libapr-1.so.0 => /usr/local/apache2.2.3/lib/libapr-1.so.0 (0xb7e8a000)librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7e81000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7e53000)libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e40000)libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e3c000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d0b000) /lib/ld-linux.so.2 (0xb7f0a000)
No openssl libraries linked to this one. Are you sure they weren't just linked into mod_ssl.so?
S. -- Sander Temme sctemme@xxxxxxxxxx PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
|