ID: 25176
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: WinXP Pro SP1
PHP Version: 5CVS-2003-08-20 (dev)
Assigned To: zeev
New Comment:
Worked this one out...
The reason is that the cgi binary has the php4ts.dll for PHP5 in its
PWD, and when it requests the dll, thats where windows looks first and
tells it that its there.
The CLI binary does NOT have a php4ts.dll for PHP5 in its PWD, so
windows traverses the %PATH%, where it finds the PHP4 php4ts.dll and
tells the binary thats where it was found.
Solution: Put a copy of php4ts.dll in c:\php5\cli if you need to run
PHP5 and PHP4 simultaneously (testing), otherwise put c:\php5 in your
path(note that when running the PHP4 binaries, they will find the PHP5
php4ts.dll, the problem is reversed).
- Davey
Previous Comments:
------------------------------------------------------------------------
[2003-08-20 18:56:58] [EMAIL PROTECTED]
Note that this *only* happens with the CLI for me. So is there some
difference in how this binary detects php4ts.dll to how the cgi one
does?
- Davey
------------------------------------------------------------------------
[2003-08-20 18:55:51] [EMAIL PROTECTED]
OK, it seems that it finds my ZDE php4ts.dll in c:\program
files\zend\bin is the one its finding (note that it didn't find the one
in c:\program files\zend\bin)
It errors with:
"The procedure entry point zend_uv could not be located in the dynamic
link library php4ts.dll" - presumably because that php4ts.dll is from
4.2.2 (IIRC).
If I then restore my c:\php4\php4ts.dll is seems to find that one
instead because the error goes back to the original one reported.
Could this be %PATH% related? Or is PHP5 looking for php4ts.dll
differently to PHP4? Note that PHP4 *also* finds the ZDE one (and
errors with the same error) if c:\php4\php4ts.dll is not there.
Something is going on here.
- Davey
------------------------------------------------------------------------
[2003-08-20 18:50:16] [EMAIL PROTECTED]
Then there is something else at play here.
I keep my PHP installs in seperate folders like this:
c:\php4\
c:\php5\
I do not move php4ts.dll to system32 or anything, it should use the
php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4
or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5
(note the cli binary is in c:\php5\cli\php.exe) and indeed when I
remove all other php4ts.dll's from my system I get:
"This application has failed to start because php4ts.dll was not found.
Re-installing the application may fix this problem."
I am now going to check which php4ts.dll it is detecting (I have quite
a few ;) and perhaps I can see why (i.e. if its the one from ZDE its
most likely that that .dll is registered with the OS and the one with
php5 is not, however PHP4 doesn't suffer from this, so something can be
done to fix this)
- Davey
------------------------------------------------------------------------
[2003-08-20 18:12:54] [EMAIL PROTECTED]
edink hit it on the head - it's not a bug, you're mixing binaries from
different builds.
In Windows there's a simple rule - if it builds, there are no missing
symbols, they just can't exist. If there are missing symbols - the
build would fail.
The only situation where you can get missing symbols is if you mix
different successfully-built binaries.
------------------------------------------------------------------------
[2003-08-20 17:55:04] [EMAIL PROTECTED]
Zeev, you touched that stuff on 18th of August..
------------------------------------------------------------------------
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/25176
--
Edit this bug report at http://bugs.php.net/?id=25176&edit=1
