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.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I have added a possible fix for this problem.
Now if crypt() is found in libc, then we don't
force adding of libcrypt anymore.