William A. Rowe, Jr. wrote:
...for 95% of the modules it *just doesn't matter*. A module that uses only apr or only system I/O or memory allocation will probably never trip up. We can build mod_jk, for example, to VC 2008 and use it on our VC6 httpd. Or we can build mod_jk with VC6 and it will still work fine on VC 2008.
Probably true. mcvcrtXX.dll will work with msvcrt.dll and vice versa, but muvcrtXX.dll won't work with msvcrtYY.dll, so that give us the only logical solution, and that is using the common denominator which is msvcrt.dll For example, httpd binaries from Apache2 Lounge are build with msvcrt80.dll. Now if you build a module with msvcrt90.dll it probably won't work because there is no chained dependencies between them, so you actually have two libraries that collide. The same situation was with httpd build against msvcrt71.dll (from hunter.campbus.com). In that case msvcrt80.dll modules behaved faulty for almost every stdio file functions. (at least we noticed that with mod_jk and it's logging) For mod_jk binaries we are linking with msvcrt.dll simply because this gives the reusability to run on httpd compiled against any consecutive (msvcrt71, msvcrt80, msvct90, msvcrtXX) version.
So I didn't mean to slight folks following [EMAIL PROTECTED], but for almost everyone the discussion would mean nothing, but to the mod_perl guys it's all much more fragile and needs coordination ;-)
Of course. Regards, Mladen
