Martin Vorlander wrote: !Hi, ! !when rebuilding Perl 5.8.0 to include the tainting bug patch, I got !several test failures. Upon looking closer into these, I saw that !most of them were caused by an ACCVIO in the backquote command called !by the runperl() function from t/test.pl. I'm running OpenVMS Alpha !V7.2-2. ! !$^X is resolved to something like disk:[path.][000000]PERL.EXE !(I have installed it into the DCLTABLES) PERL_ROOT (and thus the above !disk:[path.]) and PERLSHR point to the correct images. Could the !unresolved ".][" have something to do with it?
While that might have something to do with it I would doubt it. Note that for folks who use the foreign symbol the invokation is the same: $ show logical perl_root "PERL_ROOT" = "DKA300:[PERL.PERL.]" (LNM$PROCESS_TABLE) $ show symbol perl PERL == "$PERL_ROOT:[000000]PERL.EXE" $ perl -e "print $^X" dka300:[perl.perl.][000000]perl.exe;6 I can verify that the ".][000000]" does not impede the operation of perl using the MCR verb and the translated logical name directly from the DCL prompt: $ mcr dka300:[perl.perl.][000000]perl.exe -e "print $^X" dka300:[perl.perl.][000000]perl.exe;6 I do note that I have another perl installation on dka300:[perl.perl-5_6_1.] and if I define my PERL_ROOT to point there then try to run either of the above I see these results: $ define/trans=concealed perl_root dka300:[perl.perl-5_6_1.] $ mcr dka300:[perl.perl.][000000]perl.exe -e "print $^X" %DCL-W-ACTIMAGE, error activating image PERLSHR -CLI-E-IMGNAME, image file _DKA300:[PERL.PERL-5_6_1.][000000]PERLSHR.EXE -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image whereas the foreign symbol is happy: $ perl -e "print $^X" dka300:[perl.perl-5_6_1.][000000]perl.exe >From your decription of the problem it sounds like your PERL_ROOT points to the place where you are building and testing perl. I would recommend that you double check the value of your PERL_ROOT and if you are sure that it points to the BUILD tree (typically disk:[path.PERL-5_8_0.], as opposed to the installation location which is typically disk:[path.PERL-5_8_0_ROOT.]) then it "should" work. If it still does not you might want to try building in a different location completely. As a last resort you might need to back out your modified DCLTABLES.EXE, but I cannot offer any help with that since I have never worked with that configuration (I usually use the foreign command global symbol and have only occasionally set up a machine where I added PERL to the PROCESS symbol table with a "$ SET COMMAND PERL.CLD" in the login.com for a particular user.). Peter Prymmer
