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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
-outputresource:$@;1
> _VC_MANIFEST_EMBED_DLL= $(MT) -manifest [EMAIL PROTECTED]
-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.
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
