You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/12/28 18:51:05 UTC
Visual Studio 2008 and ActiveState Perl 5.10 updates
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
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by Issac Goldstand <ma...@beamartyr.net>.
William A. Rowe, Jr. wrote:
> Issac Goldstand wrote:
>> -0.5
>>
>> 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 :-)
>
[snip]
>
> I need to check if VS Express 2008 includes the SDK headers they omitted
> (unwisely, IMHO) from VS Express 2005.
It doesn't, AFAIK - the opposite *has* been true lately (that the SDK
includes the compiler), which is why I suggested the 80 compiler which
comes with the latest SDK (though I haven't looked at the Server 2008
SDK, which may include 90)
Issac
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
> -0.5
>
> 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 :-)
As I mentioned in my lead post, it seems the Express compiler will be
coming along with each release.
I doubt the SDK alone is going to solve the issue. I just reviewed it,
and found in 6.1 two sets of the includes (perhaps our missing msvcrt.dll
headers as well as VC9 headers?) and msvcrt.lib bound for msvcr90.dll
I think SDK 6.1 is the longhorn flavor (offhand).
An interesting observation, the DDK includes the msvcrt.lib as well as
that flavors headers, resolving my issue that they would not be available
(as it's becoming impossible to obtain VC6).
There's no /need/ to buy the VS suite if the VS Express solves the issue.
I need to check if VS Express 2008 includes the SDK headers they omitted
(unwisely, IMHO) from VS Express 2005.
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by Issac Goldstand <ma...@beamartyr.net>.
-0.5
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,
Issac
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
>
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by Jan Dubois <ja...@activestate.com>.
On Fri, 28 Dec 2007, Randy Kobes wrote:
> On Fri, 28 Dec 2007, Jan Dubois wrote:
> > Therefore I'm genuinely interested to learn where the problems are
> > if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
> > with VC7. I would expect this to work just fine if we ignore the
> > address space wasted by essentially unused surplus clibs.
>
> I'm not sure if this is a clean example, but there was
> a report:
> http://marc.info/?l=apache-modperl&m=119140365320503&w=2
> where mod_perl and Apache (compiled with VC8) did not
> work with ActivePerl (VC6), whereas switching to a mod_perl
> compiled with VC6 with the same Apache and Perl
> did (seemingly) work.
I didn't find enough information in that thread to figure out what
the problem might be. It could very well be a module issue and
not a problem with mod_perl itself.
> Also, Steve Hay reports that his Win32::SharedFileOpen
> module:
> http://search.cpan.org/src/SHAY/Win32-SharedFileOpen-3.36/INSTALL
> and his Win32::UTCFileTime module:
> http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL
> will only work with ActivePerl when they're compiled with VC6.
I've looked at both, and they indeed must be compiled using the same
runtime library as the corresponding perl5x.dll: Both modules use
core Perl APIs and either insert FILE* pointers received from the
CRT into Perl data structures, or try to turn a FILE* pointer from
Perl into a fileno using the CRT.
Both extensions contain code that should ideally be part of the core.
Or at least the core should provide the necessary thunks to access
the corresponding functions from its own CRT.
I wonder if there are many modules though that do this kind of diddling
with the PerlIO subsystem internals.
If there aren't, then I can see a few ways to resolve this:
* Maybe the functionality of these modules should be supported by
the core. I believe Steve already asked if the Win32::UTCFileTime
code shouldn't be the default for Perl's handling of filetimes.
* Maybe we should add the required thunks to Perl. E.g. add a
Perl_get_osfhandle() function etc.
* Maybe add the modules to ActivePerl and/or the PPM repositories.
(They should already be on the PPM server, but seem to be missing
due to some buildbox meltdown).
Cheers,
-Jan
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 28 Dec 2007, Jan Dubois wrote:
> On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
[ ... ]
>>>> 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.
>>>
>>> Why? What problems are going to happen?
>>
>> The major class of problems happens that there is one posix files
>> table per linked clib, one memory pool per linked clib, etc. When
>> resources cross from one to the next, that's the crux of the issue.
>
> Sure, but how do resources cross? Isn't this always a module bug
> to start with? Note that I have virtually no experience with the
> particular issues you may see with Perl inside Apache, but I've
> worked on many Perl embedding scenarios, putting Perl into COM
> controls, Windows services and .NET applications, so I'm well aware
> of the general issues, and how to solve them/work around them.
>
> Therefore I'm genuinely interested to learn where the problems are
> if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
> with VC7. I would expect this to work just fine if we ignore the
> address space wasted by essentially unused surplus clibs.
I'm not sure if this is a clean example, but there was
a report:
http://marc.info/?l=apache-modperl&m=119140365320503&w=2
where mod_perl and Apache (compiled with VC8) did not
work with ActivePerl (VC6), whereas switching to a mod_perl
compiled with VC6 with the same Apache and Perl
did (seemingly) work.
Also, Steve Hay reports that his Win32::SharedFileOpen
module:
http://search.cpan.org/src/SHAY/Win32-SharedFileOpen-3.36/INSTALL
and his Win32::UTCFileTime module:
http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL
will only work with ActivePerl when they're compiled with
VC6.
--
best regards,
Randy
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jan Dubois wrote:
> On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
>> The obvious question is; what are your include libraries for that
>> module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or
>> continue to build with VC 6?
>
> That Platform SDK headers (in case the module uses APIs that were
> introduced with Win2K or later), followed by the VC6 ones for traditional
> CRT stuff.
Bingo! Ok, so we are clear, we are still building to VC6. I just wanted
to clarify that this isn't mixing and matching to MSVCRxx headers from
a later compiler.
In theory that might even be possible, but it's only fair to point out that
it's becoming impossible to download VC6 or obtain the SDK flavor which
will actually compile under it. Or are you compiling with a more modern
VC against the older VC6 headers? (The issue with obtaining them remains).
> I don't see how Windows 9X/NT compatibility plays a role here. E.g.
> for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is
> Windows 2000, but the code is still using MSVCRT.dll for the various
> reasons I listed.
Right - understood.
> That being said, we don't go out of our way to *break* Win9X
> compatibility, but we don't test on it, and won't try to fix anything
> unless it is obvious/trivial.
:) Ditto, although I'm less vigorous about providing dynaload thunks
now, unless a 2008/Vista or 2003/XP API would break on 2000.
> I'm interested in the potential performance advantage though. Did
> you do any measurements? I've only heard anecdotal evidence of a 5%
> improvement that leaves me quite unimpressed (for things like PerlBench
> a 5% difference is almost at the noise level).
Right; we have entirely different designs on performance. For httpd,
5% would be a godsend :) I'll be collecting and reporting on such in
the near future.
>> The major class of problems happens that there is one posix files
>> table per linked clib, one memory pool per linked clib, etc. When
>> resources cross from one to the next, that's the crux of the issue.
>
> Sure, but how do resources cross? Isn't this always a module bug
> to start with? Note that I have virtually no experience with the
> particular issues you may see with Perl inside Apache, but I've
> worked on many Perl embedding scenarios, putting Perl into COM
> controls, Windows services and .NET applications, so I'm well aware
> of the general issues, and how to solve them/work around them.
Yup - it's almost always the same story; some API returns memory that
it expects the caller to free(), rather than a corresponding API release
call. There are a host of such examples in the way that mod_perl was
implemented. Even some of the API's (as I hint about the SSL modules)
which are implemented as xs's that behave similarly.
> Therefore I'm genuinely interested to learn where the problems are
> if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
> with VC7. I would expect this to work just fine if we ignore the
> address space wasted by essentially unused surplus clibs.
Right; we aren't talking about optimizing, but simply interop.
> It used to work in earlier Perl 5.8.x versions too, but later releases
> of the 64-bit VC compiler in the Platform SDK broke things. I thought
> I fixed this ages ago, but I guess I only submitted the necessary
> patches earlier this year and they had not been included in any
> official P5P release:
>
> http://public.activestate.com/cgi-bin/perlbrowse/p/30878
>
> However, there have been 64-bit ActivePerl releases of 5.8.8 on
> Windows since August 2006.
:)
> Just FYI, all the 64-bit ActivePerl on Windows releases have been built
> with the VC version from the Windows Server 2003 SP1 SDK. That compiler
> is a special version of the VS2003 compiler that links against the
> 64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in
> a special bufferoverflowU.lib library if you use the /GS compiler option
> because MSVCRT.dll doesn't include the runtime support for the buffer
> overrun detection.
Interesting detail, thanks. I had presumed as much (or that you had built
it against an earlier DDK before they incorporated this fully into the SDK).
> I may have missed these, as I only skim the mod_perl mailing lists.
> I always assumes that you would either use the Newx()/Safefree() mechanism
> from Perl, or a corresponding mechanism from APR to manage your memory.
> Mixing them can be dangerous even with a single clib because the Perl
> mechanism may use memory before and after the allocated block to detect
> buffer overruns in testing builds etc.
Right - of course should-be and are-actually are two different things :)
And it's only fair to point out this isn't win32 specific, libs linked
against an optimized allocator on various flavors of unix will blow up
in similar ways when the consuming app is linked to the 'stock' allocator.
> I sure hope that the problems can be solved by proper encapsulation of
> the different components. Re-releasing all components in sync whenever
> Microsoft releases a new compiler sounds like a very bad idea to me.
+1 - although it might not be possible for realistic applications today,
it's an admirable goal to define these API's correctly :-)
Bill
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by Jan Dubois <ja...@activestate.com>.
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> Jan Dubois wrote:
>> I still haven't seen a compelling argument why someone wants to move
>> away from using MSVCRT.dll (and then continue switching CRTs then
>> every other year).
>
> The obvious question is; what are your include libraries for that
> module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or
> continue to build with VC 6?
That Platform SDK headers (in case the module uses APIs that were
introduced with Win2K or later), followed by the VC6 ones for traditional
CRT stuff.
> I'm concerned about drift; I understand the advantages to msvcrt.dll,
> but fail to see where the proper headers are derived from, and agree
> with some other posters that the performance advantage to moving to a
> more modern compiler will outweigh the desire to remain "windows 9x"
> compatible.
I don't see how Windows 9X/NT compatibility plays a role here. E.g.
for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is
Windows 2000, but the code is still using MSVCRT.dll for the various
reasons I listed.
That being said, we don't go out of our way to *break* Win9X
compatibility, but we don't test on it, and won't try to fix anything
unless it is obvious/trivial.
I'm interested in the potential performance advantage though. Did
you do any measurements? I've only heard anecdotal evidence of a 5%
improvement that leaves me quite unimpressed (for things like PerlBench
a 5% difference is almost at the noise level).
>>> 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.
>>
>> Why? What problems are going to happen?
>
> The major class of problems happens that there is one posix files
> table per linked clib, one memory pool per linked clib, etc. When
> resources cross from one to the next, that's the crux of the issue.
Sure, but how do resources cross? Isn't this always a module bug
to start with? Note that I have virtually no experience with the
particular issues you may see with Perl inside Apache, but I've
worked on many Perl embedding scenarios, putting Perl into COM
controls, Windows services and .NET applications, so I'm well aware
of the general issues, and how to solve them/work around them.
Therefore I'm genuinely interested to learn where the problems are
if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
with VC7. I would expect this to work just fine if we ignore the
address space wasted by essentially unused surplus clibs.
>> This is not correct. All the 64-bit support code is already in Perl
>> 5.8.x as well.
>
> Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our
> favorite perlmongers to put their full attention to 5.10 first (good
> choice IMHO).
It used to work in earlier Perl 5.8.x versions too, but later releases
of the 64-bit VC compiler in the Platform SDK broke things. I thought
I fixed this ages ago, but I guess I only submitted the necessary
patches earlier this year and they had not been included in any
official P5P release:
http://public.activestate.com/cgi-bin/perlbrowse/p/30878
However, there have been 64-bit ActivePerl releases of 5.8.8 on
Windows since August 2006.
Just FYI, all the 64-bit ActivePerl on Windows releases have been built
with the VC version from the Windows Server 2003 SP1 SDK. That compiler
is a special version of the VS2003 compiler that links against the
64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in
a special bufferoverflowU.lib library if you use the /GS compiler option
because MSVCRT.dll doesn't include the runtime support for the buffer
overrun detection.
> Certainly some folks who are actively using it already will chime in,
> I'm looking forward to their specific examples - it's why I brought
> this up on modperl's list.
Yes, please speak up; I'm very interested to hear about it.
> I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of
> any new box I personally use until and if I get around to building
> perl and python myself), but point out that the glue in malloc/free,
> faux-posix entities etc that have to span httpd to apr to modperl to
> perl do have issues today that have been reported on-list.
I may have missed these, as I only skim the mod_perl mailing lists.
I always assumes that you would either use the Newx()/Safefree() mechanism
from Perl, or a corresponding mechanism from APR to manage your memory.
Mixing them can be dangerous even with a single clib because the Perl
mechanism may use memory before and after the allocated block to detect
buffer overruns in testing builds etc.
> I suspect a good number of these will, ultimately, be resolved with a
> consistent clib across all components.
>
> Alternate solution is for each component to manage it's own resources
> and abstract them for the consumer; we are getting there, slowly. The
> breadth of cpan packages doesn't make this easier ;-)
>
> For example, OpenSSL needs to be built for both a host of perl ssl
> packages and for httpd mod_ssl (and apr-util, in the near future).
It should not really matter. OpenSSL is a separate DLL and it should
work regardless which clib the user is using. Everything else would be
a bug in OpenSSL (or very poor design of the API, by e.g. accepting
a FILE* parameter directly).
I sure hope that the problems can be solved by proper encapsulation of
the different components. Re-releasing all components in sync whenever
Microsoft releases a new compiler sounds like a very bad idea to me.
Cheers,
-Jan
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jan Dubois wrote:
>
> The initial switch away from MSVCRT.dll was due to a conflict inside
> Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become
> so important to the operation of Windows itself that the compiler team
> was no longer allowed to update it; ownership had been transferred to
> the OS team and the only update vehicle was Windows Update. This made it
> impossible to include updated versions of MSVCRT.dll with Visual Studio
> releases, and the compiler team went back to versioned runtime
> libraries.
A very interesting perspective, thanks!
> I still haven't seen a compelling argument why someone wants to move
> away from using MSVCRT.dll (and then continue switching CRTs then every
> other year).
The obvious question is; what are your include libraries for that module?
The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to
build with VC 6?
I'm concerned about drift; I understand the advantages to msvcrt.dll, but
fail to see where the proper headers are derived from, and agree with some
other posters that the performance advantage to moving to a more modern
compiler will outweigh the desire to remain "windows 9x" compatible.
One aspect of my current vc perspective is that really NT 4.0 and 9x are
now "dead", as in "harmful when installed in the network cloud". So with
the loss of further security fixes to the NT4/9x class OS's, I'm moving
away from their support whatsoever for httpd 2.4 (3.0?) binaries.
>> 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.
>
> I tried back in the VS.NET days to compile with VC7 and link against
> MSVCRT.dll. It turned out to fail in some cases when compiler generated
> code (under C++) called help functions not present in MSVCRT.dll.
I'd expect that... but I'm more concerned about insidious failures which
aren't clean compile/link time exceptions.
>> 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.
>
> Why? What problems are going to happen?
The major class of problems happens that there is one posix files table
per linked clib, one memory pool per linked clib, etc. When resources
cross from one to the next, that's the crux of the issue.
>> 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.
>
> This is not correct. All the 64-bit support code is already in Perl 5.8.x
> as well.
Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our favorite
perlmongers to put their full attention to 5.10 first (good choice IMHO).
> I have no idea what you are trying to get at here, and where your
> fatalistic attitude comes from. If there is a real problem using
> ActivePerl with mod_perl, then please let me know about it. I'm
> sure we can work it out. :)
Certainly some folks who are actively using it already will chime in,
I'm looking forward to their specific examples - it's why I brought this
up on modperl's list.
I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of
any new box I personally use until and if I get around to building perl
and python myself), but point out that the glue in malloc/free, faux-posix
entities etc that have to span httpd to apr to modperl to perl do have
issues today that have been reported on-list.
I suspect a good number of these will, ultimately, be resolved with a
consistent clib across all components.
Alternate solution is for each component to manage it's own resources
and abstract them for the consumer; we are getting there, slowly. The
breadth of cpan packages doesn't make this easier ;-)
For example, OpenSSL needs to be built for both a host of perl ssl
packages and for httpd mod_ssl (and apr-util, in the near future).
Which build? One compiled on VC 9 or VC 6?
Bill
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
Posted by Jan Dubois <ja...@activestate.com>.
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> 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.
You can expect a new runtime library version for each compiler release
from Microsoft. This started back with VS.NET (MSVCR70), VS2003
(MSVCR71), VS2005 (MSVCR80) and now VS2008 (MSVCR90).
The initial switch away from MSVCRT.dll was due to a conflict inside
Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become
so important to the operation of Windows itself that the compiler team
was no longer allowed to update it; ownership had been transferred to
the OS team and the only update vehicle was Windows Update. This made it
impossible to include updated versions of MSVCRT.dll with Visual Studio
releases, and the compiler team went back to versioned runtime
libraries.
> 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.
This is not really true for Perl, which abstracts all runtime library
dependencies away. As long as you include the Perl headers in your
module code, you will use the same runtime library as Perl itself.
> 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.
This was a conscious decision: Using MSVCRT.dll as the runtime library
has many advantages: the library is already installed on *all* Windows
systems, so you never need to distribute it yourself. This is important
for tools like PAR, PerlApp and Perl2Exe that create selfcontained
executables of Perl applications. Using MSVCRT.dll also allows to use
both VC++6 and GCC from MinGW without loading duplicate runtimes.
I still haven't seen a compelling argument why someone wants to move
away from using MSVCRT.dll (and then continue switching CRTs then every
other year).
> 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.
I tried back in the VS.NET days to compile with VC7 and link against
MSVCRT.dll. It turned out to fail in some cases when compiler generated
code (under C++) called help functions not present in MSVCRT.dll.
> 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.
Why? What problems are going to happen?
> 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.
This is not correct. All the 64-bit support code is already in Perl 5.8.x
as well.
> 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.
I have no idea what you are trying to get at here, and where your
fatalistic attitude comes from. If there is a real problem using
ActivePerl with mod_perl, then please let me know about it. I'm
sure we can work it out. :)
Cheers,
-Jan