Hi Edin,
It might be that we need to change our manifest for mod_phpx.dll to
make the crt load correctly. IIRC, there was some magical way to do
this based on the resource number you use when you bake the manifest
into the module; position 1 means one thing and position 2 means
another.
I have this in one of my makefiles:
COOK_EXE_MANIFEST=if exist [EMAIL PROTECTED] mt.exe -nologo -manifest
[EMAIL PROTECTED] -outputresource:$@;1 & del [EMAIL PROTECTED]
COOK_DLL_MANIFEST=if exist [EMAIL PROTECTED] mt.exe -nologo -manifest
[EMAIL PROTECTED] -outputresource:$@;2 & del [EMAIL PROTECTED]
wonder if that's the trick for the php build? (haven't tried it myself
on windows in a few weeks).
Also note that I don't think the manifest you pasted below forces
apache to use a different libc; it should already be linked to the
right one based on its filename. This could easily be verified in a
debugger by viewing the list of loaded modules--I'd expect to see both
the old and the new crt modules in there.
--Wez.
On 1/6/07, Edin Kadribasic <[EMAIL PROTECTED]> wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
