ID:               25176
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 Status:           Open
 Bug Type:         Zend Engine 2 problem
 Operating System: WinXP Pro SP1
 PHP Version:      5CVS-2003-08-20 (dev)
 Assigned To:      zeev
 New Comment:

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


Previous Comments:
------------------------------------------------------------------------

[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..


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

[2003-08-20 16:31:28] [EMAIL PROTECTED]

I too also experienced this error in the php/php-cli dists.  I also
must note that the internal socket support throws a starnge error in
the newer snaps as well.

~ Andrew

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

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

Reply via email to