php-windows Digest 10 Jul 2013 08:28:25 -0000 Issue 4111
Topics (messages 31038 through 31040):
Re: Running more PHP-versions with php_opcache.dll
31038 by: Pierre Joye
31039 by: Jan Ehrhardt
31040 by: Jan Ehrhardt
Administrivia:
To subscribe to the digest, e-mail:
php-windows-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-windows-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-wind...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Jul 9, 2013 7:54 PM, "Jan Ehrhardt" <php...@ehrhardt.nl> wrote:
>
> Hi Pierre,
>
> Pierre Joye in php.windows (Tue, 9 Jul 2013 19:06:04 +0200):
> For what purpose should I use two php.ini's?
> For running two versions
> with their own OPcache? That is what this whole discussion is about (and
> can't be solved with just two ini's).
For having two different settings for x86 and x64. Which is what your patch
does. You already have two different DLLs.
> Or for switching between my own builds and the PGO-optimized versions
> you and your team deliver?
Php.net delivers, the fact that some people within the same team do the job
is not really relevant.
> For switching between those 2 two php.ini's
> will not do any good, because every file in my builds differ from what
> can be downloaded from PHP.net. Even trivial things like the
> snapshot.txt, but especially all the binaries. See
> http://www.apachelounge.com/viewtopic.php?t=5423 for my builds.
> ZIP-files of 35MB each for the x64 versions and about 30MB for the x85
> builds.
I do not understand why you build everything from scratch. Providing the
missing ext should be enough. Also we work with everyone to be sure that we
are all sync'ed from a VC version POV. There should not be a need to
provide custom build for php itself. But that's another discussion.
> At the moment I am uploading new x64-zip's, containing a php_opcache.dll
> (from the unmodified GIT-head sources) and a php_opcache64.dll that is
> using a differently named semaphore file.
Yes, that is IMO a bug. The filename is poorly generated and should used
less conflicting inputs.
Cheers,
Pierre
--- End Message ---
--- Begin Message ---
Hi Pierre,
Pierre Joye in php.windows (Tue, 9 Jul 2013 22:39:17 +0200):
>On Jul 9, 2013 7:54 PM, "Jan Ehrhardt" <php...@ehrhardt.nl> wrote:
>> For what purpose should I use two php.ini's?
>
>For having two different settings for x86 and x64. Which is what your patch
>does. You already have two different DLLs.
O, yes. For that purpose I have different php.ini's.
>I do not understand why you build everything from scratch. Providing the
>missing ext should be enough. Also we work with everyone to be sure that we
>are all sync'ed from a VC version POV. There should not be a need to
>provide custom build for php itself. But that's another discussion.
It started with something PHP.net did not deliver: x64 versions of PHP
5.3 and 5.4. And for me it is the easiest way to keep up-to-date. A
single build script for all extensions, with a direct check if they
load. But you are right: that is another discussion.
>> At the moment I am uploading new x64-zip's, containing a php_opcache.dll
>> (from the unmodified GIT-head sources) and a php_opcache64.dll that is
>> using a differently named semaphore file.
>
>Yes, that is IMO a bug. The filename is poorly generated and should used
>less conflicting inputs.
Steffen from Apachelounge said something interesting:
"Opcache is creating in his temp dir ...."
http://www.apachelounge.com/viewtopic.php?t=5461
Is there something as a temp dir setting for OPcache?
Jan
--- End Message ---
--- Begin Message ---
Jan Ehrhardt in php.windows (Tue, 09 Jul 2013 23:11:36 +0200):
>Pierre Joye in php.windows (Tue, 9 Jul 2013 22:39:17 +0200):
>>I do not understand why you build everything from scratch. Providing the
>>missing ext should be enough. Also we work with everyone to be sure that we
>>are all sync'ed from a VC version POV. There should not be a need to
>>provide custom build for php itself. But that's another discussion.
>
>It started with something PHP.net did not deliver: x64 versions of PHP
>5.3 and 5.4. And for me it is the easiest way to keep up-to-date. A
>single build script for all extensions, with a direct check if they
>load. But you are right: that is another discussion.
What php.net also did not deliver was versions with openssl 1.x.
I switched to that early because of this problem with curl and openssl
0.9.8h+: http://sourceforge.net/p/curl/bugs/1037/#dfa4
It might have been fixed 2 months ago:
http://sourceforge.net/p/curl/bugs/1037/?page=3
Jan
--- End Message ---
