My setups (8 of the 9 I have here): php.exe (whichever one I'm using is
named 'php.exe' in all cases, whether cli or cgi) is in the same directory
as php.ini, php*ts.dll, and the external shared libraries (e.g.
libmysqli.dll) needed to support whatever extensions that particular version
of php needs.  For users it would probably be better to put those kinds of
.dlls into system32 or an equivalent path, but I find it harder to keep
track of them that way.

I have no clue why Nuno reports that it does not work for PHP 5.  Probably
the clue's in 'set PATH'.  There's no reason to set PATH unless you're doing
something very strange with PHP.  I don't have any PHP-related environmental
variables set.  The php-specific shared libraries (e.g. php_mysqli.dll) are
in the same directory as the executable OR below it in a dir specified in
php.ini, in 8 cases. I also have a php5 executable and php5ts.dll running as
part of cygwin/bin - that's number 9.

I have both PHP 4 and 5 versions of cgi running with Apache (switch between
them depending on what I'm doing), with PHP-GTK, as cli and as testbeds.  No
conflicts.

This means that if we suggest people to replicate the PHP 5 package structure with PHP 4 (move the contents of the dlls folder and the sapi folder into the root PHP folder), and place php.ini there, then that should work without and special PATH settings either for PHP 4 or PHP 5. I wonder why this is not working for Nuno, it is/was hard to beleive...


I don't really see, why you suggest that people might be happier with moving stuff to system32. I see just the opposite. It is also harder to remove PHP that way. BTW I wonder why the installer moves stuff outside the PHP folder then...

Goba

Reply via email to