Re: Windows build

Not to drag this thread on any longer, but I think I found the issue. There is something wrong with Edin's build. A few of the modules do not have the manifest embedded. I was using bz2 and pdo for testing because I found that both php_bz2.dll and php_pdo.dll have no embedded manifest. When I built a release version myself I checked my extensions and they did have a manifest embedded, so was able to just replace those 2 extensions in Edin's build with the ones mine built and apache loaded them happily. With php_pdo.dll loaded, php_pdo_sqlite.dll (the only acutal db I was testing with) also then loaded fine (already had manifest). I don't know how many other extensions are missing a manifest or even how it happened. As far as CLI vs Apache, I think that CLI works because it loads MSVCR8.dll, so the extensions built incorrectly without an embedded manifest though having a dependancy to MSVCR8.dll (according to dep walker) use the one loaded from the .exe. Apache, not loading MSCVR8.dll or having a notion of it (hence why manually adding an apache manifest works), provides nothing for the bad extensions to key off of and they fail to load not being able to find a reference to MSVCR8.dll. Rob Wez Furlong wrote:

Hmm. I know that, in the past, I've had this kind of issue when trying to distribute modules that use the debug version of the CRT (which is itself not redistributable). I wonder if that is sneaking into the build somehow? --Wez. On 1/7/07, Rob Richards <rrichards@ctindustries.net> wrote:

Don't know if any of this will help, but here's what I've been getting while trying to use VS 2005. I'm not sure what the difference is between my debug build and the one Edin released, but when using my own build apache loads everything fine. Using Apache 2.0.59 for testing. When I change the apache config to use the one's Edin released (same php.ini settings other than pointing to the correct extension dirs), I get the issues trying to load pdo dlls. On that note, I also got different results than Edin when trying to run nmake test. Here, everything is failing (only with VS 2005 - everything works fine with VC 6 and VS 2003). After tracing it through everything looks perfectly fine, but when it tries to read the output of a test from the proc_open call, there is no output returned. When I break out the functionality and try to isolate it (using the proc calls, I can get it to work correctly). I am running this on a dual core so wonder if there is any possibility this has any bearing on my issue with nmake test. Rob Edin Kadribasic wrote:

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.