in reply to Re^5: Testing Time::Piece on Windows/VC
in thread Testing Time::Piece on Windows/VC

Hm. When I look at the mscvrt.dll that gets imported by perl510.dll from my AS 64-bit build, is loaded from c:\windows\system32\msvcrt,.dll it is versioned as Windows NT CRT DLL 7.0.6001.18000.

Now, if VC++v7 was 32-bit only. And I have VC++v9, which is also "wrong", presumably--assuming some kind of logic--the compiler that comes with SDK2003--which is the "correct version"--must be VC++v8.

Now, on my system I have 53 different copies of various msvcr*.dll, amongst them at least 8 different msvcr80.dlls:

<Reveal this spoiler or all in this thread>

As there is a v8-specific version of the CRT, the question is why does the AS built binary load the "generic" msvcrt.dll, in preference to the specific version? Presumably, the existance of the specific version means it must get used under some circumstances.

Or, more interestingly, is there some way to request (or default) extensions built using the v9 compiler to import their CRT requirements from the generic msvcrt.dll supplied with the platform (per the AS binary), rather than the tookit specific msvcr90.dll as currently?

The linker has options: /DEFAULTLIB:library /NODEFAULTLIB[:library] along with the compilers /MT & /MD options.

The generated makefile use (amongst others):-nodefaultlib Set LIBC=msvcrt.lib and add the latter to the list of filesnames supplied ot the linker. But all of that does no good (for this problem at least) as the all the .dll references within the msvcrt.lib that comes with the v9 compiler are to msvcr90.dll.

Probably, none of this means anything. Maybe, it was just a policy change on MS behalf between the v8 and v9 compilers that causes the AS binaries to import from msvcrt.dll (despite the existance of msvcr80.dll), and extensions built with v9 to import from msvcr90.dll? But somehow that doesn't ring true. At least not completely.

I'm going to pull the AS sources ikegami linked to and try building it with the v9 compiler and see which CRT ends up getting used. If it links against the generic, the problem might be solvable by modifying the makefile generation to match the AS build configuration. Worth a shot at least.

I don't know how you located the v8/2003sdk downloads? Every search I tried refused point blank to locate it. The one page I found that discussed the 2003 SDK, redirected me to the 2008 SDK when I tried the download link :(

The other problem is that AFAIK, it is impossible to run the two concurrently, and I have a couple of things that I think require the 2008 SDK.

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.
"I'd rather go naked than blow up my ass"

Replies are listed 'Best First'.
Re^7: Testing Time::Piece on Windows/VC
by syphilis (Archbishop) on Jan 28, 2010 at 07:28 UTC
    And I have VC++v9, which is also "wrong", presumably--assuming some kind of logic--the compiler that comes with SDK2003--which is the "correct version"--must be VC++v8

    By my understanding of the version numbering, you have version 9.0 (version number starts with 15.00) and I have version 8.0 (version number starts with 14.00). Mine has the same full version number as the compiler that built x64 ActivePerl (14.00.40310.41).

    I have it in my head that my x64 compiler, despite being a version 8.0 compiler, actually uses the msvcrt.dll runtime. And I also have it in my head that ActiveState elected to use it (at least partly) for that reason - though I don't recall precisely how that line of reasoning ran.

    I don't know how you located the v8/2003sdk downloads?

    Someone (probably Jan Dubois) gave it to me ... I can never find anything for myself on the MS website :-)

    Let us know how you go with the perl you build with your version 9.0 compiler. I've got my money on it being able to build Time::Piece without any test failures. I'd be interested to find out for sure.

    Cheers,
    Rob
[reply]

      I conclude that you're right that this is the result of the disparate CRTs.

      In particular, the fact that both CRTs probably have seperate copies of the environment which defeats T::P's attempts to maintain Perl's copy, the CRT copy and the process' copy in a coherent state

      If I install T::P 1.16 via PPM into my AS-binary dist, it works fine. Equally, if I build it using a Perl built from AS sources and VC++ v9, it passes all the tests. Despite that the home-built ASPerl also links to both msvcrt.dll & msvcr90.dll!?

      I also think it could be 'fixed'.

      If the fixups and work arounds to the tz* functions in T::P, were factored back into the win32 perl core, and exported from perl510.dll--and T::P imported them from there--the problem would disappear. (I think :)

      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.
[reply]
        There are some extensive comments in Piece.xs about the CRT, the environment (especially $ENV{TZ}) and tzset - specifically: 
         * Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
 * putenv() to update the CRT copy of the environment (if it is differ
+ent)
 * whenever we're about to call tzset().

        [download]
        And the 2 failing tests I get when I "mix runtimes" come from: 
        SKIP: {
    skip "can't register TZ changes in a pseudo-fork", 2 if $is_pseudo
+_fork;
    local $ENV{TZ} = "EST5";
    Time::Piece::_tzset();  # register the environment change
    my $lt = localtime;
    cmp_ok(scalar($lt->tzoffset), 'eq', '-18000');
    cmp_ok($lt->strftime("%Z"), 'eq', 'EST');
}

        [download]
        I expect that when Time::Piece is built with a compiler that uses a different runtime, Time::Piece::_tzset() registers the environment change ok, but registers it with the *wrong* runtime (for the purposes of Time::Piece, at least).

        Not sure how this could be fixed. With which runtime will Time::Piece::_tzset() register the change ?
        With the runtime of the compiler that built perl ? ... or with the runtime of the compiler that built Time::Piece ?
        I suspect it must be the latter, and the trick would be to get Time::Piece::_tzset() to register the change with the former. (Or vice-versa :-)

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom