Andi Gutmans wrote: > Although it may work for you with your applications unless all of your > 3rd party libs are compiled with VS 2005 there's a fair chance that > you'll have issues when data structures are passed between PHP which is > compiled against one CRT lib to DLLs which were compiled with older > versions (different size of structures, etc...)
Or more to the point, localized resources that actually exist in one CRT which aren't visible to the other CRT. Faux-posix I/O that MS implements is a really good example of this. If you are building to Apache httpd binaries /as shipped by the ASF/, you will want to ship these in VC6 for the lifespan of httpd 2.0/2.2. As the corner turns over to httpd 2.4 sometime soon, there's a good chance that VS2005 will be picked up at that point (and stay there for it's lifetime). I doubt ASF will pick up VS2008 quickly, given the number of clib issues that occur in each iteration of the libraries. One trouble is that AS still ships Perl built on VC6 runtime, Python on the VS2003 runtime, etc etc. Until everyone can land on VS2005 at the same approximate time, it's a game of cat and mouse. [We won't go into the lack of wisdom of MS shipping yet-another-clib for each of their compiler versions.] If you just clean up the .pdb's to the point that they import cleanly, you can really keep everyone happy, today and tomorrow. When you ditch the .pdb's, it's no longer possible to export .mak build files at all for use outside of the studio-world. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
