in reply to Re: win32 thread version
in thread win32 thread version

says 
"$Config{'archname'}-$Config{'osvers'}" eq
"MSWin32-x86-multi-thread-5.0" or
    die "Errno architecture (MSWin32-x86-multi-thread-5.0) does not ma
+tch executable architecture ($Config{'archname'}-$Config{'osvers'})";

[download]
BTW I'm now seeking the newer AS build as well

Replies are listed 'Best First'.
Re^3: win32 thread version
by syphilis (Archbishop) on Jan 04, 2008 at 06:57 UTC
    Well, that's just plain ridiculous. Your 'perl -V' quite explicitly states that "$Config{'archname'}-$Config{'osvers'}" is "MSWin32-x86-multi-thread-5.0". (Look for 'archname' and 'osvers' in the output.)

    I guess there's a rational explanation - though I really don't know what it is. How can 'perl -V' claim that 'osvers' is 5.0, but $Config{osvers} report 4.0 ? Someone has stuffed up something.

    Cheers,
    Rob
[reply]
      Thanks Rob,
      I upgraded to build 22. Your perl -M command above does render the same error, which persists exactly the same. Any ideas where I can look for stuff? Is it talking about windows or about some lower level Perl code which does the threading? Is there a way I can know the right thread version for this OS?
      I replaced errno.pm, no change.
      This is a windows box, crazy things happen often.
      Thanks again,
      Craig.
[reply]
      Craig again - the 822 AS build changes naught :-( I replaced errno with PPM but it was already up to date. Is there anything else I can try? I guess anything is possible on this OS.
[reply]
        It's not normal for 'perl -V' and $Config{osvers} to disagree on the value of 'osvers'. For as long as that discrepancy exists the problem will persist. Do you happen to have more than one version of Config.pm and/or Config_heavy.pl ? I'm wondering if there's one version in perl/site/lib and another version in perl/lib. If there is such a duplication, rename the file that specifies the 'osvers' as 4.0 (so that it can't be found). Other hacks you could try include commenting out that test in Errno.pm.

        But, somewhere along the way, someone has done something that ought not have been done, and that's what's causing this strange breakage. The one solution that will work is to completely remove your entire ActivePerl installation and re-install all over again (either 819 or 822 - won't matter) - but that probably involves some inconvenience for you. We could probably hack up a solution that doesn't involve re-installation, if only we could work out what action it was that caused the breakage in the first place.

        At some stage around build 819 (I think) ActiveState altered the order of the @INC listing and they changed the directory that contains the core modules. I'm wondering whether that is involved in the problem you're seeing ... but it's hard to tell from here :-)

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom