# Windows build - Thread: https://externals.io/message/27290 - Original archive: https://news-web.php.net/php.internals/27290 - Started by Edin Kadribasic on 2007-01-06T03:48:24+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #27290 — Edin Kadribasic — 2007-01-06T03:48:24+00:00 URL: https://externals.io/message/27290#27290 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 --- ## #27291 — Firman Wandayandi — 2007-01-06T04:32:59+00:00 URL: https://externals.io/message/27290#27291 · In reply to: #27290 Hi, > 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. > Confirmed. > 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. > I'm not sure which the best one of compiler. But agree, I think the old compiler is a right one ATM. While still investigating and finding the solution to make everything works. BTW, is it just suspend for swicthing to VC++ 8.0 or stick on the old one (for future plan) ? -- Firman Wandayandi 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. Ilia Alshanetsky --- ## #27293 — William A. Rowe — 2007-01-06T04:58:33+00:00 URL: https://externals.io/message/27290#27293 · In reply to: #27292 This sounds like a sane approach. My own 2c is that your failure to load represents a failure to correctly package the .manifest data of the individual modules; perhaps this is due to the individual modules requiring an entry for php5ts.dll? Without digging deeper, it is probably most sane to ship vc 6 (or vc 7.1) binaries for now. But I'd strongly encourage research into vc 8, not for binary distribution, but because the MS Visual Studio 2005 Express Edition (available free) is your end users' most approachable platform for exploring and compiling the sources, without the cost of other VC compilers and without the stress of fighting with the hassles of the other open compiler alternatives. Ilia Alshanetsky wrote: > Edin, > > Thanks for the detailed analysis and spending time analyzing the issue. > Based on what you've said I think our best option is to go back to VC++ > 6.0 for this release, we are too far along in the release cycle to > experiment with things. Perhaps for the next release we can revisit the > issue, assuming there an interest and a benefit of using VC++ 8.0 can be > quantified. > > > > > […] > > Ilia Alshanetsky --- ## #27294 — William A. Rowe — 2007-01-06T05:05:49+00:00 URL: https://externals.io/message/27290#27294 · In reply to: #27290 Edin Kadribasic wrote: > > 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. Questions; This is WinXP SP2 fully updated? (E.g. all security 'fixes' snuck in?) Extensions are located in the same directory as php5ts.dll itself? The webservers you are testing with use the same msvcr as the php build? (Depends.exe in the psdk or vc product is wonderful for inspecting this.) --- ## #27303 — Marcus Boerger — 2007-01-06T19:48:23+00:00 URL: https://externals.io/message/27290#27303 · In reply to: #27292 Hello Ilia, weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind 6.0 long ago :-) best regards marcus Saturday, January 6, 2007, 5:44:55 AM, you wrote: > Edin, > Thanks for the detailed analysis and spending time analyzing the > issue. Based on what you've said I think our best option is to go > back to VC++ 6.0 for this release, we are too far along in the > release cycle to experiment with things. Perhaps for the next release > we can revisit the issue, assuming there an interest and a benefit of > using VC++ 8.0 can be quantified. > > > […] > Ilia Alshanetsky Best regards, Marcus --- ## #27304 — Ilia Alshanetsky — 2007-01-06T20:08:11+00:00 URL: https://externals.io/message/27290#27304 · In reply to: #27303 From what I know Edin uses VC++ 6.0 which works just fine for our needs. So, I see no reason to move away from that unless someone can present a really good reason why it should be done. > Hello Ilia, > > weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left > behind > 6.0 long ago :-) > > best regards > marcus > > Saturday, January 6, 2007, 5:44:55 AM, you wrote: > > > […] > > > […] > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus > Ilia Alshanetsky --- ## #27305 — William A. Rowe — 2007-01-06T20:27:54+00:00 URL: https://externals.io/message/27290#27305 · In reply to: #27303 Marcus Boerger wrote: > Hello Ilia, > > weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind > 6.0 long ago :-) For reference, ActiveState python is built on Studio 2003 al la 7.1, while their perl is still built VC 6, if you are looking to coexist more peacefully with one or the other. Bill --- ## #27309 — Edin Kadribasic — 2007-01-06T21:14:17+00:00 URL: https://externals.io/message/27290#27309 · In reply to: #27305 William A. Rowe, Jr. wrote: > Marcus Boerger wrote: > > […] > > For reference, ActiveState python is built on Studio 2003 al la 7.1, while > their perl is still built VC 6, if you are looking to coexist more peacefully > with one or the other. More importantly, Apache is VC 6, and that is what was causing all the trouble with loading PHP extensions when running as an Apache module. Edin --- ## #27310 — Andi Gutmans — 2007-01-06T21:15:04+00:00 URL: https://externals.io/message/27290#27310 · In reply to: #27290 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 > > -- > To > unsubscribe, visit: http://www.php.net/unsub.php --- ## #27312 — Marcus Boerger — 2007-01-06T21:31:34+00:00 URL: https://externals.io/message/27290#27312 · In reply to: #27309 Hello Edin, ok, i thought you would use the newer stuff already. Maybe if you have all withstaticruntime it *could* work. But I happen to have thesekinds of problems ofwork as well - a lot unfortunatley. best regards marcus Saturday, January 6, 2007, 10:14:17 PM, you wrote: > William A. Rowe, Jr. wrote: > > […] > More importantly, Apache is VC 6, and that is what was causing all the > trouble with loading PHP extensions when running as an Apache module. > Edin Best regards, Marcus