#19918 [Opn]: no libphp4.so produced

From: Date: Mon, 23 Dec 2002 10:57:43 +0000
Subject: #19918 [Opn]: no libphp4.so produced
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-28262@lists.php.net to get a copy of this message
ID: 19918 User updated by: mad@dactar.ch Reported By: mad@dactar.ch Status: Open Bug Type: Apache2 related Operating System: HP-UX 11.00 PHP Version: 4.3.0-pre1 New Comment: Same result with PHP 4.3.0RC4 It's a critical bug in "Apache2 related" category. Can you change the status to critical ? @++ JC Previous Comments: ------------------------------------------------------------------------ [2002-12-11 12:04:11] mad@dactar.ch tested with php4-200212111630 same result. @++ JC ------------------------------------------------------------------------ [2002-11-26 18:46:28] pbriggs@clinitech.net Using the latest CVS snapshot php4-STABLE-200211262230, I was able to locate what I believe to be the problem. Apparently PHP is trying to link in -lcrypt, and because libcrypt.a is not a shared library object, libtool is complaining and then not creating a shared libphp.so object because of it: *** Warning: linker path does not have real file for library -lcrypt. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libcrypt and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libcrypt.a *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. So what I did was re-run the last libtool command, which is supposed to link all the objects together, and create a libphp4.so, but I took out the -lcrypt portion of the command. Once that was done, a libphp4.so was created as expected, and then a 'make install' worked also as expected putting libphp4.so into /opt/apache/modules. Starting apache so far also works without an error about 'Bad magic number'. I took a gamble that php didn't use or require the crypt library, otherwise I was half expecting to get an error from dld.sl about missing reference to 'crypt', but so far so good. ------------------------------------------------------------------------ [2002-11-21 14:27:38] mad@dactar.ch tested with php4-200211211830 same result. @++ JC ------------------------------------------------------------------------ [2002-11-19 18:59:57] pbriggs@clinitech.net I'm having the same problem and I'm using the latest CVS snapshot of php4-200211200030, HP-UX 11.00 and Apache 2.0.43. The only way I was able to work around the problem was to go into where I have apache/modules located and rename libphp4.a to libphp4.so and then 'make install' again. This seems to work, but when I try to start apache, it can't use the libphp4.so. I get this error message: Cannot load /opt/apache/modules/libphp4.so into server: Bad magic number for shared library: /opt/apache/modules/libphp4.so ------------------------------------------------------------------------ [2002-11-10 18:30:43] iliaa@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19918 -- Edit this bug report at http://bugs.php.net/?id=19918&edit=1

« previous php.bugs (#28262) next »