httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Directions for the next Perl/Python/Tcl Win32 Binaries
Date Fri, 02 Dec 2005 20:07:42 GMT
Dev-folk,

   I spoke with David Ascher over at ActiveState to explain our crossroads,
and ask which tracks they expect to follow over the near future (while it's
interesting or relevant to httpd 2.2, until httpd X is released.)  He just
confirmed I can share this summary from his Perl, Python and Tcl teams,
hopefully there are some interesting nuggets here which we might take some
cues from...

David Ascher wrote:
> Bill, others. Here's the summary, and some details:
> 
> Perl, Tcl:  VC++ 6.0 for 32 bit for the foreseeable future
> Python 2.3: VC 6.0, Python 2.4 and later, VS2003 for the foreseeable future
> 
> Details on Perl:
> 
> We plan to continue to use VC++ 6.0 for 32 bit ActivePerl on Windows
> for the future.
> 
> The disadvantages of the newer compilers are that they use a different
> runtime library for each release (msvcr70.dll for VS.NET, msvcr71.dll
> for VS2003 and msvcr80.dll for VS2005).
> 
> Unlike msvcrt.dll used by VC++ 6.0 these libraries are not part of the
> OS and are not guaranteed to be on a given Windows machine, so they
> will have to be distributed with the application.  This puts an additional
> burden on software bundling mechanisms like PerlApp, Perl2Exe and PAR.
> 
> All modules in PPM module repositories need to continue to link against
> msvcrt.dll.  Otherwise you couldn't install them into existing ActivePerl
> installations that may not have msvcrXX.dll installed.  Or each module
> distribution would have to bundle the runtime library.
> 
> Installing a module linked against msvcrXX.dll into an older ActivePerl
> will result in the loading of multiple C runtimes in one process. This
> can be a problem when any code in this process uses structured
> exception handling.
> 
> For VS2005 you also have to provide an application manifest in order
> to load msvcr80.dll from the same directory, which is an additional
> hassle. I'm not sure yet if this would really be a problem or not.
> 
> Our current setup with VC++ linking against msvcrt.dll works quite well.
> Starting with ActivePerl 815 we also seamlessly support using GCC (via
> MinGW) when VC++ 6.0 is not available on the PATH. This happens
> automatically with no additional configuration required. The GCC
> compilation still links against msvcrt.dll, so we still only use a
> single runtime library. MinGW is available for free, so we already do
> offer people a free alternative to VC++ to compile their own modules.
> 
> 
> Details on Tcl:
> 
> Same as Perl.
> 
> Details on Python:
> 
> Python 2.3 (and hence ActivePython 2.3) builds with VC6.
> The current version, Python 2.4 (and hence ActivePython 2.4), builds
> with VS2003 (VC7.1).
> 
> As Jan indicated, this means that ActivePython needs to distribute
> msvcr71.dll -- and it does (along with a couple other DLLs for full
> usability of some of the PyWin32 libraries).
> 
> Discussion on python-dev indicates that python.org's Python builds will
> continue to use VS2003 (i.e. not switch to VS2005) for the next release
> of Python at least (Python 2.5).
> 
> Maintaining binary compatibility with python.org's Python is important
> for ActivePython to ensure compatibility of all the 3rd party libraries
> out there. The current mod_python Windows binaries seem to be built with
> VS2003 as well:
>    http://www.apache.org/dist/httpd/modpython/win/
> 
> 
> 
> 
> 

Mime
View raw message