Re: Modifying Win32 default optimizations?
At 08:29 PM 5/11/2005, Randy Kobes wrote: >That sounds great, but one consideration from the point of >view of Perl (eg, mod_perl) is that the dominant Win32 Perl >binary, from ActiveState, uses VC 6 to compile, and they >don't have any plans soon of changing that. But that might >change by the next generation. There is yet another consideration which might kill this entire discussion. The beta VC++ 2005 Express includes everything one would want, nmake, cl, lib, link et al. It does not have msvcr70.lib in it's lib/ tree. It does have msvcrt.lib. In SDK\v2.0\Bin one also finds msvcr80.dll. Which means, it appears, that msvcr70.dll never 'arrived' and has been orphaned. Perhaps ActiveState took a better route with Perl than Python. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying Win32 default optimizations?
At 04:35 PM 5/11/2005, Branko Čibej wrote: >William A. Rowe, Jr. wrote: > >>If the open source community tends to push back on Microsoft's >>newest compilers, it's simply because their forced treadmill is >>the anathema of inclusiveness. >> >That's what's happening right now with Subversion. The Python 2.4 distro is >built with VS.NET (2003, I think). HTTPD is built with MSVC 6. Subversion >tries to link with both. So right now, we're stuck with either providing only >Python 2.3 bindings, or not being able to use an HTTPD from the apache.org >installer... Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR 0.9 / etc all in the same 'generation' of code. Do you want the ASF to be a leader of this 'breakage' as the Python project was? This is why the push back. And I hope for Python 2.4 / Apache 2.2 / APR 2.0 / etc to all be of the next 'generation', finally adopting msvcr70. Seem rational? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying Win32 default optimizations?
At 08:46 AM 5/11/2005, Branko Čibej wrote: >>All in all - comments? >How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? >It's time, to say the least. Not for 1.3 or 2.0 httpd - you lose some measure of binary compatibility. We can jump through hoops to continue to use the msvcrt.dll but it's suboptimal. To pick up msvcr70.dll will cause some measure of pain. I'm willing to consider moving to Visual C 7 for binary builds of httpd-2.1+ if enough of the community is behind it. For that matter, perhaps its time to drop Win9x support from httpd-2.1+ (?) If your thought is no - lots of people still use 9x - then also consider that lots of people are quite happy with their VC 5 or 6 and it just continues to work for them. Here's an example of the issue; http://mail.gnome.org/archives/dia-list/2003-March/msg00141.html Nothing stops YOU today from using VC7, in fact VisualStudio will gladly parse the .dsp files into .vcproc's, .dsw into .sln. The question, rather, is what clib and compiler to use to create the binary distributions - and right now, We obviously want users to be able to elect /GS compilation under VC7 for stack guard sentinels. If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. At 10:45 AM 5/11/2005, Branko Čibej wrote: >99% of the work of moving from MSVC6 to any flavour of VC.Net is in converting >the project files. So it doesn't matter if the target is 2003 or 2005. That would be 1% of the work. Visual Studio.NET does that work for you. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Modifying Win32 default optimizations?
I'd like to modify the Win32 build projects (of mod_jk, and httpd 1.3/2.0/2.1-dev, along with apr); The /O2 optimization option is extremely agressive, unfortunately it produces less than ideal crash traceback information. That is due to the (implicit) /Oy flag, which omits respecible stack framing. I'd like to change this to /O2 /Oy- to disable this optimization; processing will be unmeasurably slower, but far more useful when crashes do occur. The /O2 optimization also simplifies the stack frame checking for many functions. The /Gs0 option would restore full frame checks, to ensure we don't overflow the stack in the processing of any function. With FirstBill's (wise) choice to reduce the size of our default stack frames within httpd, it seems wise to be extra diligent. However, MS's docs state that /O2 implies /Gs - and I can't determine if that is /Gs0 (implied) or some other behavior. Thoughts from someone with more experience playing in stack probes would be appreciated. All in all - comments? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
