perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Date Sat, 29 Dec 2007 15:50:45 GMT

I would actually like to see builds prepared against MSVCRT80, which is
available in the Vista SDK's bundled free compiler, rather than having
users need to download the SDK + VS Express Edition + configure the one
to find and work with the other (a royal pain).  As long as the latest
SDKs are bundled with compilers (for x86, amd64 and even the ia64 for
those who find that useful) there's no reason not to keep the build
procedure as simple as possible for those of us *cough* who prefer not
to buy a new VS suite every time MS feels like trying to send me one :-)

My $0.02,

William A. Rowe, Jr. wrote:
> Well folks, here's the news...
> Studio 2008, true to form, proves that MS is incapable of keeping
> around a stdc library any longer than one product cycle.  Yes, our
> long awaited (not) MSVCR90 is here.
> Just to put it in perspective, cross-library malloc/free, stdio and
> some other facilities are tightly integrated into the clib, such that
> compiling the application under one flavor, and using a library of
> another which modifies the application's memory/stdio allocations
> causes no end of troubles.
> You might be also curious if AS is making progress at coming to a new
> baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71
> for python.  Unfortunately, this version is also built under msvcrt.
> The obvious question, why not compile apache and perl under vc 8 or 9
> but link to msvcrt.dll?  The trouble which comes in here is that their
> std headers correspond to msvcr90, not to msvcrt.  As that library
> evolves, it's going to inevitably drift from the msvcrt.lib.
> My instinct, with 2008 adding the new SDK features for apr such as
> multicast group filtering, and the continued availability of a 2008
> 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries
> for apache httpd to this 2008 release.  Yes, probably retain either
> .dsp files, or a makefile structure which allows folks to build to
> anything from VC6 to a 'plain SDK' (it now includes the compilers
> and tools), but for binaries, this will become foobar for folks who
> use ActiveState.
> Perl 5.10 is interesting for it's attention to Win32 64P model builds
> (64ILP reflects an OS which represents int, long, pointer as 64 bits,
> so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer).
> Because 64P is unusual in the family of 64 bit OS's, it's received the
> least attention of all of the platforms.  Perl 5.10 is purported to catch
> win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit
> flavors.
> So I'm posting this mostly for feedback to the rational of moving to
> a compiler that will generate reliable 32 *and* 64 bit builds of httpd,
> will be freely available (the point of the ASF is the source, and that
> users can do something with it), and that decision will be locked at
> the 2.4 release based on our strong commitment to binary compatibility.
> It's very true that modules compiled for another runtime can coexist
> very happily when the module does not free allocations from another
> component, don't attempt to share faux-posix stdio resources, etc.
> mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it
> lives very happily in a VC6 build of httpd.  But the way that perl,
> mod_perl and httpd interact is not that trivial, and highly prone to
> this class of problems.  So I figure if there's a plan here, it will
> likely satisfy the 80/20.
> If AS Perl can't part of that solution, so be it.
> Bill

View raw message