On Mon, 25 Jun 2001, Maxim, Michael wrote:
> Hello once again:
>
> Sorry about the p1/p2 params for build_perl.com; red herring, I did use the
> path for p1, not p2 as I said in a previous message, my bad (need to stop
> trying
> to type stuff from memory, got confused with what I'd tried when I was just
> trying
> to build the modules... ugh).
>
> Anyway, some more hopefully relevant results and info:
>
> P>Why did you not use this incantation?:
> P> $ set default disk:[dir.perlbuild]
> P> $ @build_perl disk:[perl5_6_1.]
>
> I don't have write access to disk:[000000], only disk:[dir] :/
Very well, sorry for being _so_ literal but the distinction betwixt
a physical dev name and something else (rooted logical, volume name, etc.)
is rather important for the purposes of creating valid rooted logical
names such as what is needed for PERL_ROOT.
My question could very well have been re-phrsed to ask:
> P>Why did you not use this incantation?:
> P> $ set default disk:[dir.perlbuild]
> P> $ @build_perl disk:[dir.perl5_6_1.]
Note that disk:[dir.perl5_6_1] need not exist prior to running
@build_perl. It should be automatically created as part of perl's
`mmk install` build step.
> P>There should be no discernable difference as far as building perl is
> P>concerned between MMS and MMK.
>
> I got this error when building with mmk, but not with mms:
> %DCL-W-ACTIMAGE, error activating image PERLSHR
> -CLI-E-IMGNAME, image file DSA70:[3WEEK_TEMP.PERL.][000000]PERLSHR.EXE;1
> -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
That is odd. I ordinarily use MMS, although I have built perl (in the
past) with MMK without a problem.
> All other things being equal, I even manually edited the perl_setup.com
> to set the directory names explicitly, no joy). So I will stick with MMS
> for now.
>
> C>replace this line near the top of build_perl.com:
> C>$ topdir = f$parse(whoami,,,"DEVICE") + f$parse(whoami,,,"DIRECTORY")
> C>with the following version:
> C>$ topdir = f$parse(whoami,,,"DEVICE","NO_CONCEAL") +
> f$parse(whoami,,,"DIRECTORY")
>
> Still got the link error for the undefined symbols, and the module builds
> all die
> with the following explaination:
>
> (You get this message, because MakeMaker could not find
> "perl_root:[lib.VMS_VAX.
> 5_6_1.CORE]perl.h")
>
> and/or vmsish.h.
>
> C>Thanks for your persistence and keep us posted. Have you started working
> on
> C>the IA64 version of Perl for VMS yet ;-)?
>
> Thank you all for the responses and suggestions, greatly appreciated. I'm
> on the
> wrong end of food chain to make IA64 programs or applications, but some of
> the
> equipment we used to MAKE the IA64 chips generate these gorgeous (and
> enormous)
> log files that are just begging me to parse and slurp into a database for
> some
> really esoteric analysis... ;) We care about nanometers nowdays, fun fun.
>
> Gotta get modules to make in perl first tho. :/ Once/if I get that done,
> any
> suggestions for a good rdb for vms? :)
You have spent a fair amount of time using the build_perl.com procedure.
Perhaps you ought to instead try an "everytthing by hand" type of build.
With perl:
set def [.perl-5_6_1]
@configure "-Dprefix=disk:[dir.perl5_6_1_install.]" "-des"
mms
mms test
mms install
copy perl_setup.com some_disk:[some_dir]
With modules:
@ some_disk:[some_dir]perl_setup
gunzip module.tar-gz
tar -xvf module.tar
set def [.module_dir]
perl makefile.pl
mms
mms test
mms install
repeat the last 7 steps for all of the modules you'll want to have
installed.
For Rdb access from perl try the DBI and DBD::Rdb driver. The latter you
can find from Andreas Stiller:
http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2001-02/msg00083.html
that used to be at sidhe.org - I cannot find it on CPAN nor on
sidhe.org???
Another hard to find module (that I am not sure if it is a part of the
buildperl kit or not) for VMS is at:
ftp://www.sidhe.org/smg.zip
Peter Prymmer
