On Sat, 9 Nov 2002, Chris wrote: > I'd heard rumors that there was an attempt to build a version > of Perl using VC++ 7 because Microsoft has a free > non-optimizing VC++ compiler they ship with the .NET SDK. I was > very excited by this prospect. ::sigh::
I asked Jan Dubois at ActiveState about this, just to verify - the relevant excerpt of his reply follows ... ============================================================ On Sat, 9 Nov 2002 22:31:53 -0600 (CST), Randy Kobes <[EMAIL PROTECTED]> wrote: Hi Randy, >I was wondering about the 5.8 repository at >http://www.activestate.com/ppmpackages/5.8-windows/ - it doesn't >seem to include packages that need a C compiler, like DBI. Is it >just too early for these, or is there a reason for this? Yes, the current repository is just the result of the first automated run for ActivePerl 8xx. We already noticed that even some of the modules that always used to pass are still missing. I think the release notes of build 802 say somewhere that you shouldn't expect a full repository until ActivePerl 8xx comes out of *beta*. You just need a little patience. :) >Perhaps related to this, was this build compiled with VC++ 6? Yes. For various reasons, we decided to continue to build ActivePerl with VC++ 6 SP3. I'm pretty sure that later service packs should be compatible too as the core Perl code doesn't use C++ anymore (the PERL_OBJECT stuff contained pointers to member functions, which changed size in VC++ 6 SP4 and later). I've also (just for testing) compiled extension DLLs for ActivePerl 633 and 802 using the free, non-optimizing VC++ 7 compiler from the .NET Framework SDK. It worked just fine, but it will use MSVCR70 instead of MSVCRT for the runtime library, resulting in 2 different C runtime libraries being loaded. This is potentially a problem with structured exception handling for C++, but should work fine for "normal" C extension code too. Cheers, -Jan ============================================================ -- best regards, randy
