Perl (for OpenSSL) v. me

[Steven Schweda]

The new OpenSSL builders rely on a modern Perl. Figuring
"What could go wrong?", I sucked down a Perl 5.22.1 kit, and
built it on a VMS Alpha V8.4 system. The build seemed to
work:

ALP $ perl --version

This is perl 5, version 22, subversion 1 (v5.22.1) built for VMS_AXP
[...]

As did most of the tests:

[...]
Failed 5 tests out of 2140, 99.77% okay.
../cpan/HTTP-Tiny/t/140_proxy.t
../cpan/Pod-Simple/t/search50.t
../cpan/Test-Harness/t/proverun.t
io/argv.t
run/locale.t
[...]

The OpenSSL builders require one particular package:

ALP $ perl Configure vms-alpha
Can't locate Text/Template.pm in @INC (you may need to install the
Text::Template module) (@INC contains: /perl_root/lib/site_perl/VMS_AXP
/perl_root/lib/site_perl /perl_root/lib/VMS_AXP/5_22_1 /perl_root/lib
.) at Configure line 1248.
BEGIN failed--compilation aborted at Configure line 1248.
%SYSTEM-F-ABORT, abort

And the OpenSSL docs suggest the following as a remedy:

cpan -f -i "Text::Template"

This was not a roaring success:

ALP $ cpan -f -i "Text::Template"
Loading internal null logger. Install Log::Log4perl for logging messages

CPAN.pm requires configuration, but most of it can be done automatically.
If you answer 'no' below, you will enter an interactive dialog for each
configuration option instead.

Would you like to configure as much as possible automatically? [yes]
ALP::_RTA2: 11:01:26 perl CPU=00:30:37.99 PF=4936 IO=3605916 MEM=3042
ALP::_RTA2: 11:01:34 perl CPU=00:30:45.72 PF=4937 IO=3621096 MEM=3043
ALP::_RTA2: 12:02:57 perl CPU=01:28:46.40 PF=7183 IO=10491370 MEM=3719
ALP::_RTA2: 13:00:48 perl CPU=02:24:01.44 PF=8338 IO=17110867 MEM=4019

Apparently, "yes" was not the best answer. With "no":

[...]
Where is your gpg program? []
Where is your patch program? [patch]
Where is your patch program? [patch]
Where is your patch program? [patch]
Where is your patch program? [patch]
[...]

Found the loop. This was the only such query with a non-empty
default response. A space instead of a null response got me
past that one. Continuing on with default responses...

[...]
If no urllist has been chosen yet, would you prefer CPAN.pm to connect
to the built-in default sites without asking? (yes/no)? [yes]

Would you like me to automatically choose some CPAN mirror
sites for you? (This means connecting to the Internet) [yes]

unknown name or service at /perl_root/lib/CPAN/Mirrors.pm line 564.
%SYSTEM-F-ABORT, abort

Not entirely satisfactory. Repeating the procedure using a pre-built
PCSI kit for Perl v5.22.1 gave the same results.

I tried subscribing to vmsperl-...@perl.org, but got
no prompt response. (I could be blocking something, but
e-mail from addresses near perl.org should be getting
through.)

So, I'm open to suggestions on how to get a working Perl
with "Text::Template", so that I can get onto the next
failure.

[Dennis Boone]

> So, I'm open to suggestions on how to get a working Perl
> with "Text::Template", so that I can get onto the next
> failure.

For quick-and-dirty getting on with, you can just download the tarballs
for these modules and build them by hand.

http://search.cpan.org/CPAN/authors/id/M/MJ/MJD/Text-Template-1.46.tar.gz

Extract the tarball and try:

perl Makefile.PL
mmk
mmk install

De

[Craig A. Berry]

On 2/4/16 10:54 PM, Steven Schweda wrote:
> The new OpenSSL builders rely on a modern Perl.

>

> And the OpenSSL docs suggest the following as a remedy:
>
> cpan -f -i "Text::Template"
>
> This was not a roaring success:

It was for me with the 5.22.1 binary kit installed:

$ cpan -i Text::Template

Loading internal null logger. Install Log::Log4perl for logging messages

Reading 'D0:[CRAIG._cpan]Metadata'
Database was generated on Thu, 03 Dec 2015 19:17:02 GMT
Fetching with HTTP::Tiny:
http://cpan.mirrors.tds.net/authors/01mailrc.txt.gz
Reading 'D0:[CRAIG._cpan.sources.authors]01mailrc.txt.gz'
............................................................................DONE
Fetching with HTTP::Tiny:
http://cpan.mirrors.tds.net/modules/02packages.details.txt.gz
Reading 'D0:[CRAIG._cpan.sources.modules]02packages.details.txt.gz'
Database was generated on Fri, 05 Feb 2016 06:17:02 GMT
HTTP::Date not available
............................................................................DONE
Fetching with HTTP::Tiny:
http://cpan.mirrors.tds.net/modules/03modlist.data.gz
Reading 'D0:[CRAIG._cpan.sources.modules]03modlist.data.gz'
DONE
Writing D0:[CRAIG._cpan]Metadata
Running install for module 'Text::Template'
Fetching with HTTP::Tiny:
http://cpan.mirrors.tds.net/authors/id/M/MJ/MJD/Text-Template-1.46.tar.gz
Fetching with HTTP::Tiny:
http://cpan.mirrors.tds.net/authors/id/M/MJ/MJD/CHECKSUMS
Checksum for
D0:[CRAIG._cpan.sources.authors.id.M.MJ.MJD]Text-Template-1.46.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring M/MJ/MJD/Text-Template-1.46.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a MMK-style Descrip.MMS
Writing Descrip.MMS for Text::Template
Writing MYMETA.yml and MYMETA.json
MJD/Text-Template-1.46.tar.gz
DSA0:[SYS0.SYSCOMMON.perl-5_22.][000000]perl.exe;1 Makefile.PL -- OK
Running make for M/MJ/MJD/Text-Template-1.46.tar.gz
cp [.lib.Text.Template]Preprocess.pm [.blib.lib.Text.Template]Preprocess.pm
cp [.lib.Text]Template.pm [.blib.lib.Text]Template.pm
MJD/Text-Template-1.46.tar.gz
MMK -- OK
Running make test
MCR DSA0:[SYS0.SYSCOMMON.perl-5_22]perl.exe.1 "-MExtUtils::Command::MM"
"-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0,
'[.blib.lib]', '[.blib.arch]')" t/*.t
t/00-version.t ..... ok
t/01-basic.t ....... ok
t/02-hash.t ........ ok
t/03-out.t ......... ok
t/04-safe.t ........ ok
t/05-safe2.t ....... ok
t/06-ofh.t ......... ok
t/07-safe3.t ....... ok
t/08-exported.t .... ok
t/09-error.t ....... ok
t/10-delimiters.t .. ok
t/11-prepend.t ..... ok
t/12-preprocess.t .. ok
t/13-taint.t ....... ok
t/14-broken.t ...... ok
All tests successful.
Files=15, Tests=150, 7 wallclock secs ( 0.64 usr + 0.00 sys = 0.64 CPU)
Result: PASS
MJD/Text-Template-1.46.tar.gz
MMK test -- OK
Running make install
Installing perl_root:[lib.site_perl.Text]Template.pm
Installing perl_root:[lib.site_perl.Text.Template]Preprocess.pm
Appending installation info to perl_root:[lib.VMS_IA64.5_22_1]perllocal.pod
%MMK-I-ACTNOUPD, action did not update target INSTALL
%MMK-I-ACTNOUPD, action did not update target INSTALL
MJD/Text-Template-1.46.tar.gz
MMK install -- OK

I think the obvious difference from your set-up is that I already have
CPAN configured, and have had for some time, so if something broke in
first-time configuration, I wouldn't see it. The configuration is just a
text file located at [._cpan.CPAN]MyConfig.pm with a Perl data structure
in it, so the easiest way to fix it, given the interactive tool is not
working right, might just be to start with a working one and edit it to
your heart's content. Here's what mine looks like -- just replace
"DISK$USER" and "[me." with appropriate local values:

$CPAN::Config = {
'applypatch' => q[],
'auto_commit' => q[0],
'build_cache' => q[100],
'build_dir' => q[DISK$USER:[ME._cpan.build]],
'build_dir_reuse' => q[0],
'build_requires_install_policy' => q[yes],
'bzip2' => q[],
'cache_metadata' => q[1],
'check_sigs' => q[0],
'colorize_output' => q[0],
'commandnumber_in_prompt' => q[1],
'connect_to_internet_ok' => q[1],
'cpan_home' => q[DISK$USER:[ME._cpan]],
'curl' => q[],
'ftp' => q[],
'ftp_passive' => q[1],
'ftp_proxy' => q[],
'getcwd' => q[cwd],
'gpg' => q[],
'gzip' => q[],
'halt_on_failure' => q[0],
'histfile' => q[DISK$USER:[ME._cpan]histfile],
'histsize' => q[100],
'http_proxy' => q[],
'inactivity_timeout' => q[0],
'index_expire' => q[1],
'inhibit_startup_message' => q[0],
'keep_source_where' => q[DISK$USER:[ME._cpan.sources]],
'load_module_verbosity' => q[none],
'lynx' => q[],
'make' => q[],
'make_arg' => q[],
'make_install_arg' => q[],
'make_install_make_command' => q[],
'makepl_arg' => q[],
'mbuild_arg' => q[],
'mbuild_install_arg' => q[],
'mbuild_install_build_command' => q[@Build.com],
'mbuildpl_arg' => q[],
'ncftp' => q[],
'ncftpget' => q[],
'no_proxy' => q[],
'pager' => q[more],
'patch' => q[],
'perl5lib_verbosity' => q[none],
'prefer_external_tar' => q[0],
'prefer_installer' => q[MB],
'prefs_dir' => q[DISK$USER:[ME._cpan.prefs]],
'prerequisites_policy' => q[follow],
'scan_cache' => q[atstart],
'shell' => undef,
'show_unparsable_versions' => q[0],
'show_upload_date' => q[0],
'show_zero_versions' => q[0],
'tar' => q[],
'tar_verbosity' => q[none],
'term_is_latin' => q[1],
'term_ornaments' => q[1],
'test_report' => q[0],
'trust_test_report_history' => q[0],
'unzip' => q[disk$user:[util.zip]unzip.exe],
'urllist' => [q[http://cpan.mirrors.tds.net/],
q[http://cpan.cse.msu.edu/], q[http://httpupdate23.cpanel.net/CPAN/]],
'use_sqlite' => q[0],
'version_timeout' => q[15],
'wget' => q[],
'yaml_load_code' => q[0],
'yaml_module' => q[YAML],
};
1;
__END__

Or for your immediate problem, you can forget about CPAN and just get
the Text::Template tarball from:

http://search.cpan.org/CPAN/authors/id/M/MJ/MJD/Text-Template-1.46.tar.gz

unpack it, and run:

$ perl Makefile.PL
$ mmk
$ mmk test
$ mmk install

> I tried subscribing to vmsperl-...@perl.org, but got
> no prompt response. (I could be blocking something, but
> e-mail from addresses near perl.org should be getting
> through.)

There is moderation and it can take a day or three for the volunteers
who run the lists to approve requests. At least that's my best guess
about what's going on.

> So, I'm open to suggestions on how to get a working Perl
> with "Text::Template", so that I can get onto the next
> failure.

So you now have two ways. If you get really desperate, here's a third.
Text::Template is quite a simple module and only has two files in it
that do any real business. You can take them from the tarball and copy
them to their canonical locations below, replacing VMS_IA64 with VMS_AXP
in directory names if running on Alpha and granting world RE access:

$ dir/col=1/nohead/notrail perl_root:[lib.site_perl...]
PERL_ROOT:[lib.site_perl]Text.DIR;1
PERL_ROOT:[lib.site_perl]VMS_IA64.DIR;1
PERL_ROOT:[lib.site_perl.Text]Template.DIR;1
PERL_ROOT:[lib.site_perl.Text]Template.pm;1
PERL_ROOT:[lib.site_perl.Text.Template]Preprocess.pm;1
PERL_ROOT:[lib.site_perl.VMS_IA64]auto.DIR;1
PERL_ROOT:[lib.site_perl.VMS_IA64.auto]Text.DIR;1
PERL_ROOT:[lib.site_perl.VMS_IA64.auto.Text]Template.DIR;1
PERL_ROOT:[lib.site_perl.VMS_IA64.auto.Text.Template].packlist;1

The .packlist file is just a list of the other files installed:

$ type PERL_ROOT:[lib.site_perl.VMS_IA64.auto.Text.Template].packlist
perl_root:[lib.site_perl.Text.Template]Preprocess.pm
perl_root:[lib.site_perl.Text]Template.pm

[Steven Schweda]

Thanks for the info.

> [...] The configuration is just a
> text file located at [._cpan.CPAN]MyConfig.pm [...]

This, I'll guess, is a user-specific file, and the path is relative
to SYS$LOGIN. Mine (SYSTEM's) is pretty sparse:

ALP $ type [._cpan.CPAN]MyConfig.pm
1;
ALP $

> [...] just replace

> "DISK$USER" and "[me." with appropriate local values:

Again, is this supposed to be SYS$LOGIN - "]"? So 'build_dir' has
nothing to do with where Perl was installed? Or is that where your Perl
was installed? Knowing nothing, a more explicit description of
"appropriate local values" might be more helpful.

> [...] so if something broke in
> first-time configuration, I wouldn't see it. [...]

Might be educational to try it.

> Or for your immediate problem, [...]

I'll give that a try (and report back).

[Craig A. Berry]

On 2/6/16 9:05 PM, Steven Schweda wrote:
> Thanks for the info.
>
>> [...] The configuration is just a
>> text file located at [._cpan.CPAN]MyConfig.pm [...]
>
> This, I'll guess, is a user-specific file, and the path is relative
> to SYS$LOGIN. Mine (SYSTEM's) is pretty sparse:
>
> ALP $ type [._cpan.CPAN]MyConfig.pm
> 1;
> ALP $
>
>> [...] just replace
>> "DISK$USER" and "[me." with appropriate local values:
>
> Again, is this supposed to be SYS$LOGIN - "]"? So 'build_dir' has
> nothing to do with where Perl was installed? Or is that where your Perl
> was installed? Knowing nothing, a more explicit description of
> "appropriate local values" might be more helpful.

Like many Unix-oriented utilities, CPAN maintains a preferences and
local workspace location under a dot-prefixed directory within the
user's home directory that would, on Unix, be ~/.cpan, but on VMS, as a
concession to ODS-2, is SYS$LOGIN:_cpan.DIR.

The build directory, as the name implies for a tool that builds Perl
extensions, is where it's going to build things. My installation of
Text::Template left the following in mine:

$ dir [._cpan.build]*Templat*.DIR

Directory D0:[craig._CPAN.BUILD]

Text-Template-1^.46^.DIR-xilXPq.DIR;1

Total of 1 file.

>> [...] so if something broke in
>> first-time configuration, I wouldn't see it. [...]
>
> Might be educational to try it.

Been there, done that, fixed a number of bugs. The new bugs tend to
exceed my ability to keep up.

[BillPedersen]

Steve:

When I first saw your message I tried some of what you were having problems with and saw some strangeness, too. But along the way, I remembered some comments from Craig about CRTL Feature Logicals. So, I DEASSIGN'd all the DECC$* logicals that were local to my process.

I then invoked "CPAN" just by itself - no arguments - and it came back and said that it needed to configure. I gave it the automatic option - and off it went - no errors.

The I did:

$CPAN "TEXT::Template"

CPAN and Perl went off without a hitch and fetched TEXT::Template, installed it, and ran the tests - no errors.

So, if you have CRTL Feature Logicals - consider getting them cleared out.

Best,
Bill.

[Steven Schweda]

> So, if you have CRTL Feature Logicals - consider getting them cleared out.

ALP $ show logical DECC$*

(LNM$PROCESS_TABLE)

(LNM$JOB_82EBF440)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

"DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR_EV56"
"DECC$SHR" = "SYS$SHARE:DECC$SHR_EV56"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
ALP $

As "HELP CRTL Feature_Logical_Names" says:

[...]
NOTES

o Do not set C RTL feature logical names for the system.
Set them only for the applications that need them,
because other applications including OpenVMS components
depend on the default behavior of these logical names.
[...]

Generally speaking, I take that advice seriously, so I don't set
them. When I have a program which needs one (like, say, UnZip or Zip),
then I use decc$feature_set_value() in a LIB$INITIALIZE routine inside
the program, instead.

[Steven Schweda]

> I'll give that a try (and report back).

Manually installing the Text::Template kit worked well enough.

The new OpenSSL configuration process failed pretty miserably,
however. Apparently, abs2rel() isn't doing anything useful on VMS.
Below is a reduced script which shows some absolute paths and some
relative paths derived from the absolute paths. Compare the results on
a handy Mac with the same thing on VMS:

mba$ perl --version

This is perl 5, version 18, subversion 2 (v5.18.2) built for
darwin-thread-multi-2level
[...]

alp $ perl --version

This is perl 5, version 22, subversion 1 (v5.22.1) built for VMS_AXP
[...]

mba$ cat ../os.pl
use strict;
use File::Basename;
use File::Spec::Functions qw/:DEFAULT abs2rel rel2abs catpath splitpath/;
use Cwd qw/:DEFAULT realpath/;

my $srcdir = catdir(realpath(dirname($0)));
my $blddir = catdir(realpath("."));
my $dofile = abs2rel(catfile($srcdir, "util/dofile.pl"));

my $srcdir_rel = abs2rel($srcdir);
my $blddir_rel = abs2rel($blddir);
my $dofile_rel = abs2rel($dofile);

print "srcdir: $srcdir\n";
print "blddir: $blddir\n";
print "dofile: $dofile\n";

print "srcdir_rel: $srcdir_rel\n";
print "blddir_rel: $blddir_rel\n";
print "dofile_rel: $dofile_rel\n";
mba$

Results:

mba$ perl ../os.pl
srcdir: /Users/sms
blddir: /Users/sms/itrc
dofile: ../util/dofile.pl
srcdir_rel: ..
blddir_rel: .
dofile_rel: ../util/dofile.pl

alp $ perl ../os.pl ! ("[-]os.pl" works the same.)
srcdir: DISK$VMS083ALP:[SMS]
blddir: DISK$VMS083ALP:[SMS.itrc]
dofile: DISK$VMS083ALP:[SMS.util]dofile.pl
srcdir_rel: DISK$VMS083ALP:[SMS]
blddir_rel: DISK$VMS083ALP:[SMS.itrc]
dofile_rel: DISK$VMS083ALP:[SMS.util]dofile.pl

The relative paths on the UNIX-like system look ok, but these
not-very-relative-looking VMS paths get fiddled with further, and
end up transformed into completely fictional stuff which thoroughly
fouls the OpenSSL configuration stuff. M. Levitte suggests that Perl
5.10.1 worked for someone on VMS. I haven't tried anything older than
5.22.1, so I know nothing. Knowing nothing, I can't say that the Perl
code actually makes sense, but if abs2rel() is supposed to do more than
nothing, then something's wrong here.

[John E. Malmberg]

On 2/7/2016 1:58 AM, Steven Schweda wrote:
>> I'll give that a try (and report back).
>
> Manually installing the Text::Template kit worked well enough.
>
> The new OpenSSL configuration process failed pretty miserably,
> however. Apparently, abs2rel() isn't doing anything useful on VMS.
> Below is a reduced script which shows some absolute paths and some
> relative paths derived from the absolute paths. Compare the results on
> a handy Mac with the same thing on VMS:

Perl on VMS has multiple personalities based on PERL* and DECC$* logical
names that are documented in the VMS specific readme files.

I think the behavior of abs2rel() on VMS is also documented in those
files. It may not be able to reliably convert an absolute path name to
relative on VMS in some cases.

The default for the v5.2x PCSI kits is:

* Assume VMS format ODS-5 file names on output.[1]
* Accept either VMS format or Unix file names.[2]
* Exit with traditional exit code instead of C
program encoded actual exit code.

[1] Add on CPAN modules may not be aware of ODS-5 format names and apply
older Perl ODS-2 conventions regardless of the settings.

[2] Some Perl modules assume that VMS <-> UNIX path translations are
always reversible. That is not true and will cause issues in some cases.

If you want output for a Unix style build procedure, you will probably
have to set the appropriate logical names.

Perl 5.22 will also detect when it it was launched from the updated GNV
Bash shell and go into the Unix mode with C encoded exit code.

Currently work is underway to improve how Bash and Perl interoperate, so
there are some issues if a Perl script expects bash to be invoked
instead of DCL.

My recommendation is to use the Bash alias command to map the Perl
images needed to where Perl is installed.

The updated Bash, Coreutils, Grep, Gawk, ar_tools, ld_tools, make, and
sed kits can be installed and used to run many configure and resulted
generated make files with out installing the HP or VSI *GNV* kits.

The newest hobbyist layered product downloads as of Jan 2016 should have
the current ALPHA C compiler with the fix for the 64 bit argv pointer issue.

Regards,
-John

[Craig A. Berry]

abs2rel works fine if you give a path to which your current working
directory is relative using the same flavor of the device name you would
see from SHOW DEFAULT:

$ show def
D0:[CRAIG.TEST]
$ perl -"MFile::Spec::Functions=abs2rel" -e "print
abs2rel('D0:[craig.test.util]dofile.pl');"
[.util]dofile.pl

The problem with os.pl is that realpath is returning a device name based
on the volume label (DVI$_LOGVOLNAM I believe it's called), but that's
not what your current working directory is using. You can get your
example to work correctly by setting your current working directory
using LOGVOLNAM:

$ set def DISK$I64SYS:[craig.test]
$ perl os.pl
srcdir: disk$i64sys:[craig.test]
blddir: DISK$I64SYS:[craig.TEST]
dofile: [.util]dofile.pl
srcdir_rel: []
blddir_rel: []
dofile_rel: [.util]dofile.pl

If there is a bug, it looks like it's in realpath:

$ perl -"MCwd=realpath" -e "print realpath('d0:[craig.test]');
disk$i64sys:[craig.test]

I will try to put that on my list of things to look at.

[Steven Schweda]

> The problem with os.pl is that realpath is returning a device name
> based on the volume label (DVI$_LOGVOLNAM I believe it's called), but

> that's not what your current working directory is using. [...]

Yup.

> If there is a bug, it looks like it's in realpath:

Agreed. I normally never use those DISK$ logical names, so it's not
clear to me why anyone would drag them into the conversation without an
explicit invitation.

> I will try to put that on my list of things to look at.

If 5.10.1 really did work for OpenSSL, then I's guess that something
changed (for the worse?) since then.

[Craig A. Berry]

On 2/7/16 10:23 AM, Steven Schweda wrote:
>> The problem with os.pl is that realpath is returning a device name
>> based on the volume label (DVI$_LOGVOLNAM I believe it's called), but
>> that's not what your current working directory is using. [...]
>
> Yup.
>
>> If there is a bug, it looks like it's in realpath:
>
> Agreed. I normally never use those DISK$ logical names, so it's not
> clear to me why anyone would drag them into the conversation without an
> explicit invitation.

Me either, but it wasn't me, it was the authors of LIB$FID_TO_NAME.

We have our own realpath implementation in Perl because the one in the
CRTL only works when you have a POSIX root and
DECC$POSIX_COMPLIANT_PATHNAMES defined, which means it's completely
useless for those of living in the ancient world of disks and directories.

Perl's realpath implementation (written by John Malmberg about 10 years
ago) first gets the device name by calling stat() and then passes the
st_devnam and st_ino fields to LIB$FID_TO_NAME. stat() gives you
something that looks like DVI$_FULLDEVNAM in st_devnam and
LIB$FID_TO_NAME gives you something that looks like DVI$_LOGVOLNAM in
the output file spec (these are my best guesses but I don't have the
sources or the time to test exhaustively).

All of that seems reasonable enough and it does give you a real path. It
does not necessarily, however, give you a path that corresponds to the
output of SHOW DEFAULT even if you are on the same disk as the file in
question. I think the cause may already be lost after the stat call
because that drills through any concealed logical names and gives you a
real device that may or may not match SYS$DISK even if they are really
the same device. ALLOCLASS and SHADOWING probably figure in here too
somewhere.

I'm open to suggestions on how to fix this. I see nothing in the standard at

<http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html>

that offers any clues about what realpath should do when devices can be
known by so many different names.

>> I will try to put that on my list of things to look at.
>
> If 5.10.1 really did work for OpenSSL, then I's guess that something
> changed (for the worse?) since then.

The behavior is the same under 5.10.0 (don't have 5.10.1 handy anywhere
at the moment). So yes, something changed, but I don't think it's Perl.

[ric...@levitte.org]

Den söndag 7 februari 2016 kl. 08:58:58 UTC+1 skrev Steven Schweda:
> M. Levitte suggests that Perl 5.10.1 worked for someone on VMS.

Not quite. I believe you refer to this part of my announcement on openssl-dev:

> - Perl! Reports tell me that version 5.10.1 works fine but might need

That was perl in general, not perl on VMS specifically. The report is based on what versions of core modules came with different versions of perl, and someone (I can't remember who for the moment) helped me determine that 5.10.1 had good enough compatibility. Of course, that person is based on Unix.

But anyhow, this discussion tells me I should avoid realpath() like the plague, at least on VMS. I'll see what I can figure out (I think rel2abs() from File::Spec might do the trick).

[ric...@levitte.org]

Den söndag 7 februari 2016 kl. 08:58:58 UTC+1 skrev Steven Schweda:

A quick experience with changing 'realpath' to 'rel2abs' (which is essentially a no-op on an absolute directory spec) gave much better results when I tried:

$ def/trans=(conc,term) foo dsa20:
$ perl ../os.pl
srcdir: USER:[LEVITTE]
blddir: USER:[LEVITTE.TMP]
dofile: USER:[LEVITTE.util]dofile.pl
srcdir_rel: USER:[LEVITTE]
blddir_rel: USER:[LEVITTE.TMP]
dofile_rel: USER:[LEVITTE.util]dofile.pl
$ edit [-]os.pl ! Here's where I change 'realpath' to 'rel2abs'
$ perl ../os.pl
srcdir: FOO:[LEVITTE]
blddir: FOO:[LEVITTE.TMP]
dofile: [-.util]dofile.pl
srcdir_rel: [-]
blddir_rel: []
dofile_rel: [-.util]dofile.pl

Quite telling.

realpath() is more for the benefit of Unix, to clean out things like /../ in paths like 'foo/../bar' while making sure it doesn't trip over symlinks and the like. Quite obviously unnecessary on other VMS, down to outright wrong.

I'll fix Configure.

[Craig A. Berry]

On 2/9/16 2:25 AM, ric...@levitte.org wrote:
> Den söndag 7 februari 2016 kl. 08:58:58 UTC+1 skrev Steven Schweda:
>> M. Levitte suggests that Perl 5.10.1 worked for someone on VMS.
>

> Not quite. I believe you refer to this part of my announcement on
> openssl-dev:
>
>> - Perl! Reports tell me that version 5.10.1 works fine but might
>> need
>
> That was perl in general, not perl on VMS specifically. The report
> is based on what versions of core modules came with different
> versions of perl, and someone (I can't remember who for the moment)
> helped me determine that 5.10.1 had good enough compatibility. Of
> course, that person is based on Unix.

5.10.1 was a good release and an important one given that it broke the
logjam and got releases going again after a few years without one. But
by my count there have been 25 stable releases since then (current is
5.22.1) and I can't think of a good reason to be using a release that
old anymore.

> But anyhow, this discussion tells me I should avoid realpath() like
> the plague, at least on VMS. I'll see what I can figure out (I think
> rel2abs() from File::Spec might do the trick).

I agree. The more I think about it, the more it seems to me that using
realpath() and also using abs2rel() are at odds with each other on any
platform. realpath() is supposed to peel back on the convenience layers
(symlinks, concealed logicals, etc.) and abs2rel(), at least when called
without its optional base argument, is supposed to give you a path
relative to the current working directory of the current user session,
which is expressed in terms of those convenience layers.

[VAXman-]

In article <n9e2ph$h9u$1...@dont-email.me>, "Craig A. Berry" <craig...@nospam.mac.com> writes:
>On 2/9/16 2:25 AM, ric...@levitte.org wrote:
>> Den söndag 7 februari 2016 kl. 08:58:58 UTC+1 skrev Steven Schweda:
>>> M. Levitte suggests that Perl 5.10.1 worked for someone on VMS.
>>
>
>> Not quite. I believe you refer to this part of my announcement on
>> openssl-dev:
>>
>>> - Perl! Reports tell me that version 5.10.1 works fine but might
>>> need
>>
>> That was perl in general, not perl on VMS specifically. The report
>> is based on what versions of core modules came with different
>> versions of perl, and someone (I can't remember who for the moment)
>> helped me determine that 5.10.1 had good enough compatibility. Of
>> course, that person is based on Unix.
>
>5.10.1 was a good release and an important one given that it broke the
>logjam and got releases going again after a few years without one. But
>by my count there have been 25 stable releases since then (current is
>5.22.1) and I can't think of a good reason to be using a release that
>old anymore.

When did .1 come of age? I have 5.22.0.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Craig A. Berry]

On 2/10/16 6:27 AM, VAX...@SendSpamHere.ORG wrote:
> In article <n9e2ph$h9u$1...@dont-email.me>, "Craig A. Berry" <craig...@nospam.mac.com> writes:

>> current is 5.22.1

> When did .1 come of age? I have 5.22.0.

Just before Christmas.

[VAXman-]

In article <n9fbvp$4ni$1...@dont-email.me>, "Craig A. Berry" <craig...@nospam.mac.com> writes:
>On 2/10/16 6:27 AM, VAX...@SendSpamHere.ORG wrote:

>> In article <n9e2ph$h9u$1...@dont-email.me>, "Craig A. Berry" <craig...@nospam.mac.com> writes:
>

>>> current is 5.22.1

>
>> When did .1 come of age? I have 5.22.0.
>

>Just before Christmas.

Thanks. I was busy world travelling at that time, so I probably missed any
notice.

[Carl Friedberg]

A bit of publicity, try www.vmsperl.com from time to time. I don't have any
kind of feed (nor any ads) but there is little activity except to try to
publicize Craig's latest release. And thank you, Craig, for keep Perl so
well maintained. Carl

> _______________________________________________
> Info-vax mailing list
> Info...@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>

[ric...@levitte.org]

Den onsdag 10 februari 2016 kl. 02:15:15 UTC+1 skrev Craig A. Berry:
> [perl] 5.10.1 was a good release and an important one given that it broke the

> logjam and got releases going again after a few years without one. But
> by my count there have been 25 stable releases since then (current is
> 5.22.1) and I can't think of a good reason to be using a release that
> old anymore.

OpenSSL is used quite widely and on machinery that hasn't been updated for various reasons (uhmmm, "it works, don't fix it!", but that'd be rather silly, considering). But yeah, we've had reports from people who are stuck with old perl versions, and it was determined that 5.10.1 was a good minimum recommendation (you can go older as well, but that comes with a price).

[ric...@levitte.org]

Den onsdag 10 februari 2016 kl. 19:35:05 UTC+1 skrev Carl Friedberg:
> A bit of publicity, try www.vmsperl.com from time to time. I don't have any
> kind of feed (nor any ads) but there is little activity except to try to
> publicize Craig's latest release. And thank you, Craig, for keep Perl so
> well maintained. Carl

Ah, thanks for that bit of info.

[Steven Schweda]

While I'm at it, a couple of other, minor Perl-on-VMS complaints:

Using the PCSI kit ("VMSPORTS AXPVMS PERL522 V5.22-1"), I see:

%DCL-I-SUPERSEDE, previous value of PERL_ROOT has been superseded

because there are two DEFINE commands for PERL_ROOT in
SYS$COMMON:[perl-5_22]perl_setup.com. The perl_setup.com in the 5.22.1
source kit is different enough not to do this.

Either way, perl_setup.com looks at P1 to let the user specify a
directory explicitly (default: the directory where perl_setup.com
resides):

[...]
$ if P1 .EQS. ""
$ then
$ myproc = f$environment("PROCEDURE")
[...]
$ root_spec = myroot_dev + "[" + myroot_dir + ".]"
$ else
$ root_spec = P1
$ endif
[...]

But there's no comment in there to explain this. The victim must puzzle
it out for himself. (Or find some documentation somewhere else?)

[Craig A. Berry]

On 2/10/16 9:56 PM, Steven Schweda wrote:
> While I'm at it, a couple of other, minor Perl-on-VMS complaints:
>
> Using the PCSI kit ("VMSPORTS AXPVMS PERL522 V5.22-1"), I see:
>
> %DCL-I-SUPERSEDE, previous value of PERL_ROOT has been superseded
>
> because there are two DEFINE commands for PERL_ROOT in
> SYS$COMMON:[perl-5_22]perl_setup.com. The perl_setup.com in the 5.22.1
> source kit is different enough not to do this.

The perl_setup.com in the PCSI kit starts from the one generated at
configuration time in the source kit but it looks like there is an
automated edit that has gone haywire and duplicated the DEFINES. Thanks
for the heads up.

> Either way, perl_setup.com looks at P1 to let the user specify a
> directory explicitly (default: the directory where perl_setup.com
> resides):
>
> [...]
> $ if P1 .EQS. ""
> $ then
> $ myproc = f$environment("PROCEDURE")
> [...]
> $ root_spec = myroot_dev + "[" + myroot_dir + ".]"
> $ else
> $ root_spec = P1
> $ endif
> [...]
>
> But there's no comment in there to explain this. The victim must puzzle
> it out for himself. (Or find some documentation somewhere else?)

The victim isn't expected to need to mess with it. The P1 handling is
primarily there for use when installing from source where it specifies
the target location, which (since you haven't installed yet) isn't the
current location where the command procedure resides.

[ric...@levitte.org]

Den fredag 5 februari 2016 kl. 05:54:06 UTC+1 skrev Steven Schweda:
> The OpenSSL builders require one particular package:
>
> ALP $ perl Configure vms-alpha
> Can't locate Text/Template.pm in @INC (you may need to install the
> Text::Template module) (@INC contains: /perl_root/lib/site_perl/VMS_AXP
> /perl_root/lib/site_perl /perl_root/lib/VMS_AXP/5_22_1 /perl_root/lib
> .) at Configure line 1248.
> BEGIN failed--compilation aborted at Configure line 1248.
> %SYSTEM-F-ABORT, abort

I was a bit surprised to read this a few days ago but didn't get around to figure it out before now. I s'pose that you've unpacked with VMSTAR (yes of course you have), which converts periods in directory names to underscores, even on ODS-5 disks (I just discovered)...

You see, Text::Template is bundled in the source, exactly so our users won't have to install unless they really want to, and we have a fallback mechanism that uses the bundled stuff if it isn't installed on the local system. However, it's an unpack of a downloaded tarball, and Perl module are notorious for having a version number in the unpack directory (just like everyone else).

So, suffice to say that our fallback mechanism (roughly) used this to point at the bundled location:

use lib $srctop."external/perl/Text-Template-1.46/lib";

... yeah, you can see what went wrong. I've just committed a change (pending review) that adds this line:

use lib $srctop."external/perl/Text-Template-1_46/lib";

and voilà, it uses the fallback on this VMS box where Text::Template isn't globally installed.

Cheers,
Richard

[Steven Schweda]

> I was a bit surprised to read this a few days ago but
> didn't get around to figure it out before now. I s'pose that
> you've unpacked with VMSTAR (yes of course you have), which
> converts periods in directory names to underscores, even on
> ODS-5 disks (I just discovered)...

Since version V3.5-pre10 (2010) there's been an option,
/DOTS ("d"), to suppress the dot-to-underscore conversion on
directories, but it's an option, not the default (because
those dots are so annoying on VMS).

> [...] I've just committed a change (pending review) that
> adds this line: [...]

If it looks in both places, then what could go wrong?

[ric...@levitte.org]

Den fredag 12 februari 2016 kl. 07:08:40 UTC+1 skrev Steven Schweda:
> > [...] I've just committed a change (pending review) that
> > adds this line: [...]
>
> If it looks in both places, then what could go wrong?

I'm sure you can come up with something ;-)

In the mean time, it's better than failing more times than not.

Cheers,
Richard