[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: php4.so, undefined symbol: RAND_load_file (Apache 1.3)

On Fri, Dec 30, 2005 at 07:12:20PM -0500, Julien Lamarche wrote:
>  For MapTools' FGS base with Chamelon, I used it's own install script.

Did you run the install script as root, or as your normal user?
Which destination directory did you specify when asked?

I haven't really used FGS myself so far, but if I'm understanding
things correctly, the underlying installation concept is to provide a
more or less self-contained setup with its own apache and all required
libraries, including its own version of libssl, and a busload of other
private stuff.

> (...)
> After it still doesn't work.
> -----------------------------------------------------
> picard:/home/jlam# apachectl configtest
> Syntax error on line 245 of /etc/apache/httpd.conf:
> Cannot load /usr/lib/apache/1.3/libphp4.so into
> server: /usr/lib/apache/1.3/libphp4.so: undefined symbol: RAND_load_file

Generally, the RAND_load_file symbol that libphp4.so is missing is
supposed to be provided by libcrypto, as you can verify by doing

$ nm -D /lib/libcrypto.so.0.9.7 | grep RAND_load
00087390 T RAND_load_file

(also see http://www.openssl.org/docs/crypto/RAND_load_file.html)

As you probably figured from this URL, libcrypto is part of the OpenSSL
package, and on debian, libssl is dynamically linked against libcrypto:

$ ldd /lib/libssl.so.0.9.7
        libcrypto.so.0.9.7 => /lib/libcrypto.so.0.9.7 (0x40032000)
        libdl.so.2 => /lib/libdl.so.2 (0x40138000)
        libc.so.6 => /lib/libc.so.6 (0x4013b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Yet, for some reason I can't tell, the libssl shipped with FGS does _not_
depend on libcrypto.so.0.9.7

$ ldd /tmp/fgs/lib/libssl.so.0.9.7
        libdl.so.2 => /lib/libdl.so.2 (0x400ca000)
        libc.so.6 => /lib/libc.so.6 (0x400cd000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Debian's libphp4.so does not explicitly load libcrypto, but instead is
relying on libssl to pull it in as a secondary dependency...
The net effect of all this would be that the symbol would simply not be
made available, in case FGS's libssl should be used.

IOW, I suppose what's happened is that the install script (or you :)
somehow messed up things, so the wrong libssl is being used now.
I can't tell the exact reason, but maybe we'll find out...

One possible issue could be that the LD_LIBRARY_PATH setting (which
the FGS installation needs to run) somehow still is in effect.  In the
setenv.sh script that comes with the FGS package, you can see that it
prepends its own lib path

AFAICT, the installation instructions suggest to source this setenv.sh
in .bashrc.
Have you done that, maybe?  If so, in which .bashrc - yours, or root's?
Anything else along these lines you might have done (intentionally or
inadvertently), but then have forgotten about?

Quoi qu'il en soit... salut, bonne chance, et bonne année!

(aka 'madame ldd' ;)

Reply to: