in reply to Testing Time::Piece on Windows/VC

From the results so far, it looks as though it's only MS compilers that are producing the failures - yet I have no problem with either MSVC++ 7.0 or Platform SDK for Windows Server 2003 R2.

However, I use each of those compilers only with a perl that was built by that compiler. Lots of people use an MS compiler that did *not* build the perl on which it's being run - eg using MSVC++ 7,8 or 9 with Active Perl (which was built for and by MSVC++ 6.0). IIRC, BrowserUk uses a compiler that's different from the compiler that built his perl ... not sure about cdarke's set up.
Lots of times, this doesn't matter, but every now and then it does (because of the mixing of C runtimes that occurs) - and I speculate that this is one of those occasions where it *does* matter.

That being so, there's nothing much that Craig can do about it. I guess he could put code in the Makefile.PL that checks that the MSVC++ 6.0 is being used (iff ActivePerl is being used && the compiler is 'cl') - and then abort the build if that's not the case. From memory, Steve Hay did something like that with Win32::SharedFileOpen.

Update: In further support of my speculation that the problem comes from mixing MS compilers, I just built Time-Piece-1.16 on ActivePerl using MSVC++ 7.0, and indeed got the failure earlier reported by cdarke, plus one other failure:
t/02core.t ...... 1/95 # Failed test at t/02core.t line 60. # got: '39600' # expected: '-18000' # Failed test at t/02core.t line 61. # got: '' # expected: 'EST' # Looks like you failed 2 tests of 95. t/02core.t ...... Dubious, test returned 2 (wstat 512, 0x200) Failed 2/95 subtests (less 5 skipped subtests: 88 okay)
Yet there's no test failure building Time::Piece with that MSVC++ 7.0 compiler on a perl that was built by MSVC++ 7.0.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: Testing Time::Piece on Windows/VC
by Anonymous Monk on Jan 27, 2010 at 16:16 UTC
    Are the commands/flags used the same?
      Are the commands/flags used the same?

      I don't think there's any significant difference between my build of perl (using MSVC++ 7.0) and ActivePerl. Here's my 'perl -V':
      Summary of my perl5 (revision 5 version 10 subversion 0) configuration +: Platform: osname=MSWin32, osvers=6.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=und +ef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D +_CONSOLE DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_ +SYS -DUSE PERLIO', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='13.00.9466', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64 +', lseeks ze=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -l +ibpath:"c \_32\perl_vc7\5.10.0\lib\CORE" -machine:x86' libpth=C:\vsnet\VC7\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib + comdlg3 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uui +d.lib ws2 32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.l +ib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool +.lib com lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib + uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvc +rt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt: +ref,icf libpath:"c:\_32\perl_vc7\5.10.0\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO Built under MSWin32 Compiled at Nov 6 2008 22:28:28 @INC: C:/_32/perl_vc7/5.10.0/lib C:/_32/perl_vc7/site/5.10.0/lib .
      Cheers,
      Rob
Re^2: Testing Time::Piece on Windows/VC
by cdarke (Prior) on Jan 27, 2010 at 17:05 UTC
    Just to confirm, I downloaded the ActiveState binary, I did not build it. I have built several XS modules successfully using this compiler version (13.10.6030 for 80x86) of cl.
Re^2: Testing Time::Piece on Windows/VC
by ikegami (Patriarch) on Jan 27, 2010 at 20:01 UTC

    IIRC, BrowserUk uses a compiler that's different from the compiler that built his perl ...

    He's using an ActivePerl build, and they use a MS compiler. He was testing with a different version of MS's compiler than they use (I think), but I have never heard of any issues with doing that.

      He was testing with a different version of MS's compiler than they use (I think), but I have never heard of any issues with doing that.

      If the compiler he's using uses a C runtime other than msvcrt.dll then there can be "issues". And the fact that the MSVC++ 7.0 build of Time::Piece on ActivePerl fails (yet succeeds when perl has been built with MSVC++ 7.0) suggests to me that Time::Piece could be susceptible to such "issues".

      But this is, of course, no more than speculation on my part ... and I could be wrong.
      The simplest way to demonstrate that I am wrong would be for someone to come up with Time::Piece test failures when using the same compiler that built their perl. I think that would clearly demonstrate that there's something other than "runtime mixing" at play.

      UPDATE: One of the "issues" that can arise is touched on at http://cpansearch.perl.org/src/SHAY/Win32-SharedFileOpen-3.41/INSTALL. Specifically, it (correctly) states there:
      "In particular, this module will not work correctly if it loads a different C run-time DLL to that loaded by perl itself".

      Cheers,
      Rob

        I'd love build my own copy of Perl--if I could get hold of a copy of AS' source tree.

        I'd build my packages using MS VC++ 7 so as to be compatible with the AS 64-bit builds, but I don't believe it is available for download any more.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.