Front page | perl.par |
Postings from November 2006
Re: perl_ck_warn_d not found in perl58.dll (win 32)
Thread Previous
|
Thread Next
From:
Glenn Linderman
Date:
November 1, 2006 09:46
Subject:
Re: perl_ck_warn_d not found in perl58.dll (win 32)
Message ID:
4548DD62.7010303@NevCal.com
On approximately 11/1/2006 3:16 AM, came the following characters from
the keyboard of Roderich Schupp:
> On 10/31/06, Glenn Linderman <perl@nevcal.com> wrote:
>> >> On two separate fresh installations of Windows by now, with
>> >> corresponding fresh installations of Perl. And I consistently get a
>> >> failure
>> >>
>> >> .\par.exe -I../myldr/.. -I../blib/lib -I"d:/GUI/par/trunk/inc"
>> >> -I"C:/Perl/site/lib" -I"C:/Perl/lib" -I"d:/GUI/par/trunk" -I"." -q -B
>> >> -O..\script\parldyn.exe
>> >> Perl lib version (v5.8.8) doesn't match executable version (v5.8.3) at
>> >> C:/Perl/lib/Config.pm line 46.
>> I can only conclude that the message is erroneous: is that a bug in Perl
>> CORE, rather than PAR? Or does PAR augment the checks here, or
>> erroneously fake out the parameters???
>
> No, but the error message doesn't say what you think it says:
> the "Perl lib" in question is Confiig.pm (where this error message comes
> from)
> and the "executable" is par.exe which is actually a special purpose
> Perl interpreter (that's why it's linked against perl58.dll). The
> message is issued
> when the Perl version hardcoded into Config.pm doesn't match $[ (which is
> "located" in perl58.dll). As you found out your setup somehow picked up
> the stray perl58.dll version 5.8.3 in c:\windows\system32.
Well, this sort of addresses issue #1.
There's clearly some room for improvement in the message, if you have to
explain what it means to me, and I still don't understand it afterwards.
Clearly you understand it, if you are attempting to explain it to me.
Mind you, I'm not trying to argue with you, I appreciate the response...
the below is just explaining why I don't understand your explanation,
and also why I don't understand the error message.
I understand that par.exe is a special purpose Perl interpreter... a
replacement for perl.exe. I understand (but that is issue #2) that it
is/was linking against c:\windows\system32\perl58.dll which is/was
version 5.8.3. I understand that my installed perl is version 5.8.8,
and that it would be best if par.exe picked up a 5.8.8 perl58.dll
I don't understand _why_ the build process picks up perl58.dll from
c:\windows\system32 instead of c:\perl\bin (but that is issue #2).
I don't understand how this message is useful by reading it, if it calls
the version in the executable the "lib version" and the version of the
library the "executable version".
Reading the code for Config.pm didn't help Rob or I understand this back
in April, either... http://www.nntp.perl.org/group/perl.par/2333
Reading it today doesn't help either. Reading config.pod today doesn't
help either, although the following section now stands out (but is
incomprehensible to me, so I don't know if it relates to this issue or
not...):
> =head1 WARNING
>
> Because this information is not stored within the perl executable
> itself it is possible (but unlikely) that the information does not
> relate to the actual perl binary which is being used to access it.
>
> The Config module is installed into the architecture and version
> specific library directory ($Config{installarchlib}) and it checks the
> perl version number when loaded.
>
> The values stored in config.sh may be either single-quoted or
> double-quoted. Double-quoted strings are handy for those cases where you
> need to include escape sequences in the strings. To avoid runtime variable
> interpolation, any C<$> and C<@> characters are replaced by C<\$> and
> C<\@>, respectively. This isn't foolproof, of course, so don't embed C<\$>
> or C<\@> in double-quoted strings unless you're willing to deal with the
> consequences. (The slashes will end up escaped and the C<$> or C<@> will
> trigger variable interpolation)
The relevant code from Config.pm is
> die "Perl lib version (v5.8.8) doesn't match executable version ($])"
> unless $^V;
>
> $^V eq v5.8.8
> or die "Perl lib version (v5.8.8) doesn't match executable version (" .
> sprintf("v%vd",$^V) . ")";
So it would seem that the so-called "lib version" is the version of
Config.pm that gets bundled with something, and the so-called
"executable version" is the value of $^V.
So since Perl is made of two pieces, the perl.exe and the perlNN.dll,
the only way I can make what is happening fit is if the $^V reflects the
version of perlNN.dll rather than perl.exe.
So it would seem that the message should read:
"Config.pm version (v5.8.8) doesn't match perl58.dll version (v5.8.3)"
I'm not sure what the history is that makes it read the way it does, but
it surely is confusing the way it reads now, for reasonable
interpretations of "lib version" and "executable version".
If the things were called what they actually are, then diagnostics would
be more useful.
Is there actually a check for the version of perl.exe vs perl58.dll ?
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
Thread Previous
|
Thread Next