Re: Windows build

Hey Wez, We have: _VC_MANIFEST_EMBED_EXE= $(MT) -manifest $@.manifest -outputresource:$@;1 _VC_MANIFEST_EMBED_DLL= $(MT) -manifest $@.manifest -outputresource:$@;2 which should embed the manifest. It works for CLI/CGI but somehow does not work wiht Apache (old CRT). Actually it works for implicit loading apache.exe -> php5apache2.dll -> php5ts.dll. Somehow it does not work when PHP tries to load an extension on startup. Edin Wez Furlong wrote: > 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 $@.manifest mt.exe -nologo -manifest > $@.manifest -outputresource:$@;1 & del $@.manifest > COOK_DLL_MANIFEST=if exist $@.manifest mt.exe -nologo -manifest > $@.manifest -outputresource:$@;2 & del $@.manifest > > 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 <edin@krug.dk> 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:edin@krug.dk] >> >> 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 >> >> >