On Sat, 09 Feb 2008, William A. Rowe, Jr. wrote:
Randy Kobes wrote:
We might see what compiling the ppm with .pdb files (not sure if you
do that already) - simply /Zi args to CL.exe and /debug /opt:ref to
the linker (rather than /release). Of course you can unpack the httpd
symbols from the
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
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
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
PerlIO_teardown() calls PerlIO_debug(), which doesn't take an aTHX
argument, but assumes the TLS still points to a valid interpreter (it
contains a dTHX macro call). This seems like a bad assumption to me;
calling PERL_SYS_TERM before all interpreters have been destroyed is
a bug. Therefore I
On Fri, 08 Jun 2007, Foo JH wrote:
I wonder if I am alone in experiencing this. Simply put: putting 'use
Win32::OLE' in my modperl package will cause the Apache to fault. It
basically can't start at all. A window will pop up complaining about
'Apache HTTP Server has encountered a problem and
On Tue, 30 Nov 2004, Stas Bekman wrote:
What about the solution of ithreads? Originally ithreads were storing
their context in ThreadLocalStorage, and this didn't work under mp2,
so it was rewritten to store the context in a perl PL_ interpreter
global, now ithreads can be run inside the same
On Mon, 29 Nov 2004, Stas Bekman wrote:
Jan, do you have any idea why the CLONE trick doesn't work? CLONE is
running inside the newly-clonned perl, so thread-safety shouldn't get
on the way, no?
Is CLONE running inside the new *thread* ? It is not good enough to run
it in the correct Perl
On Mon, 29 Nov 2004, Stas Bekman wrote:
If you just call perl_clone it runs in the new perl context, but
inside the same thread. At least on Unix. Under ithreads.pm it
probably starts a new thread first (but I'm not sure). Under
modperl 2, there is no 1:1 relationship between interpreters and
On Tue, 21 Sep 2004, Steve Hay wrote:
(Non-Win32 users: The real issue here is not Win32-specific.)
As to Win32::Shortcut: you should just delete the END block from the module.
I see that Sarathy already did this over a year for the version that ships
with ActivePerl. He also gave me his
On Tue, 21 Sep 2004, Jan Dubois wrote:
There is also a race condition when 2 modules try to call CoUninitialize(),
e.g. Win32::Shortcut and Win32::OLE. If Win32::Shortcut has been loaded last,
then its END block will be executed first, and the DESTROY methods of all
still existing Win32::OLE
On Tue, 21 Sep 2004, Steve Hay wrote:
I'm a little wary of this fix because MSDN docs say An apartment must
call CoUninitialize once for each successful call it has made to
CoInitialize and CoUninitialize should be called on application
shutdown, but it certainly seems to work and is less
On Mon, 08 Dec 2003 11:27:36 -0800, Stas Bekman [EMAIL PROTECTED] wrote:
Jan Dubois wrote:
We observe the following mod_perl test failures on HP-UX 11.00 on PA-RISC,
with both HP C and GCC in both 32 bit and 64 bit mode. They are not
present on IPF systems in any of these combinations
On Thu, 04 Dec 2003 12:03:34 -0800, Stas Bekman [EMAIL PROTECTED] wrote:
THELLA,RITA (HP-Cupertino,ex3) wrote:
After installing HP-c patches, make test is working fine.
Great. What're HP-c patches?
On HP-UX for PA-RISC, version 11.00/11.11 you need to install patch
PHSS_29484/PHSS_29485 if you
14 matches
Mail list logo