Hi Andi,
Turns out the problem is that Apache is building their binaries using
VC6 so wrong CRT gets loaded. The only solution I found was to tell
Windows to load Apache with msvcr80.dll instead of msvcr.dll by suppling
a manifest file in Apache bin directory. If you crate
Apache.exe.manifest that contains:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50608.0' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
The Apache will load PHP and PHP will be able to load extensions. It
probably isn't good idea to force a different C Runtime on Apache like this.
Regarding performance, I found that on Zend/bench.php the improvement
was only marginal (2%) compared to huge increase (25-30%) when disabling
thread support.
http://edin.dk/archives/25-Benchmarks.html
Edin
Andi Gutmans wrote:
> Hi Edin,
>
> Thanks for trying to get this to work!
>
> I think eventually it'll be the right move to go to VC8 but I agree that if
> it risks a successful 5.2.1 release then it might not be worth doing that
> right now. If you can share with us a reproducing case we can try and look
> into it and see if we can get it to work. So far we have concentrated on
> CLI/CGI/FastCGi because that's the most feasible way of running, but I agree
> that you also need to get the other methods to run.
>
> For those who are curious, there are some significant performance
> improvements in VC8. Our tolower() optimization which is significant is only
> for VC8, the compiler creates significantly faster code (on par with Intel
> C/C++ compiler), and I believe some of the CRT functions like time() are
> also much faster. So I think it's definitely worth upgrading but it should
> be well timed.
>
> Anyway, let us know and we'll try and dig deeper and help get this puppy
> ported and update the build. There probably is some work that needs to be
> done on the 3rd party libs.
>
> Thanks.
>
> Andi
>
>> -----Original Message-----
>> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
>> Sent: Friday, January 05, 2007 7:48 PM
>> To: PHP Internals List
>> Subject: [PHP-DEV] Windows build
>>
>> Hey,
>>
>> It seems that VC++ 8.0 (Visual Studio 2005) brings more
>> trouble that its worth. Mainly the way it deals with the C
>> runtime. After spending hours and hours of trying to figure
>> out the way to make PHP work under Apache on Windows and be
>> able to load extensions, I'm throwing in the towel.
>>
>> I can get PHP to work fine on the command line, both cgi and
>> cli. It also works fine under IIS using fastcgi. But loading
>> sapi dll into a webserver (not using php.exe or php-cgi.exe)
>> works for the sapi itself, but trying to load any extensions
>> via php.ini fails miserably. Sometimes you will get an error
>> that the C runtime was attempted to be loaded in an illegal
>> way, sometime PHP will claim that the extension does not exist, etc.
>>
>> I looked around at other projects and everyone seems to be
>> using VC++ 6.0 for their builds (Active state, apache, ...)
>> which eliminates all the hassle with bundling C runtime, etc.
>>
>> So I think the best thing for us would be to stick to the
>> good old C compiler for making the Windows distro.
>>
>> Edin
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List To
>> unsubscribe, visit: http://www.php.net/unsub.php
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
