On 05.06.2009 16:43, Andy Wang wrote: > Mladen, Rainer, > Thanks for pointing out the crlf thing, I discovered that myself last > night and was going to update this thread this morning but you beat me > to it. :) > > I just automatically, use the tarballs since I'm normally a Unix guy. I > figure this out when I inadvertently used the Apache tarball instead of > win zip and wondered why I got the same error trying to load the .dsps. > > Mladen, I am not anywhere near remotely a Windows guy. This is my first > experience compiling stuff in a Microsoft world since using Turbo C++ > back in college, and that was DOS :). > With that in mind, can you elaborate on what the VS2005 MSVCRT71 issues > might be? The problem is, Visual Studio 6 is not available from MSDN, > and we don't have it readily available here. It appears to be a product > circa 1998, so I thought a newer compiler might not be a bad idea. > > I don't know if you recall an e-mail from Jess Holle regarding a > "quieter" logging patch that he asked for comments on. Until we have > time to look into Rainer's idea of stopping the nodes via the mod_jk > status worker, we're using our patch for now, thus the need to build our > own mod_jk.
Mladen might like to elaborate more, but in short: MS binaries need a Microsoft Visual C++ Runtime library to run with. Those are called msvcrt. The library version used is determined during the dynamic linking done with visual studio. Now if you use an extensible application like Apache, and the web server and the modules you want to load are compiled with different Visual Studio versions, multiple and possibly incompatible version of the msvcrt libs will be loaded during runtime. Until now, the official downloads of the Apache web server are compiled with VS6, so our mod_jk Windows binaries are also compiled with VS6 in order to circumvent possible havoc. I did see mod_jk compiled with newer VS version running in the standard Windows Apache from the web server download page, but you *might* run into trouble. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
