#19918 [Opn]: no libphp4.so produced
| From: | mad at dactar dot ch | 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