ID:               19918
 User updated by:  [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 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] [EMAIL PROTECTED]

tested with php4-200212111630

same result.

@++
JC

------------------------------------------------------------------------

[2002-11-26 18:46:28] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

tested with php4-200211211830

same result.

@++
JC

------------------------------------------------------------------------

[2002-11-19 18:59:57] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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

Reply via email to