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 ... export LD_LIBRARY_PATH=$FGS_HOME/lib:$LD_LIBRARY_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! Almut (aka 'madame ldd' ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
