Article 174538 of comp.os.vms:
In article <97072404171818@rdwarf.ingenius.com>, bmclaughlin@rdwarf.ingenius.com writes:
> Hello. I got the latest PERL gzip file and am attempting to install it
> on an OpenVMS  VAX system. This system is running VMS 7.0 and UCX 4.1
> ECO 6 and DEC C 5.2.  So far, I  am having no luck at all. The
> documentation that came with PERL is terrible, as is  most of the VMS
> PERL documentation I found on the web.

I agree that the installation docs for VMS Perl need work; we're trying
to improve them to cover the new options made available by recent
versions of VMS and DECC.  If you've got specific suggestions, please
let me know.  You may also want to look at some of Dan Sugalski's
recent work at www.sidhe.org; he's made a good start to working in
the new options.

> Since I have UCX rather then a third party stack or a shareware stack,
> I figured it  would be better to not use SOCKETSHR and NETLIB.
> However, some of the web  documentation differs on whether or not
> netlib and socketshr are required. After  multiple unsuccessful

The important criterion is not what sort of socket routines you've
got, but what sort of stdio routines.  One of the ways in which
Perl shows its Unix heritage is that is expects stdio calls to
work for both regular files and sockets.  Until recently, the
DECCRTL didn't have this capability; VAXC never has.  As a result,
you need to use SOCKETSHR to provide the necessary stdio shims,
unless you're using a recent version of DECC (>= 5.2, I think,
but as it's the DECCRTL that really counts, recent VMS versions
may suffice as well).  Whether you use NETLIB or UCX (real or
emulated) as the backend doesn't matter.

> builds, I attempted to install SOCKETSHR. It wouldn't build  either
> and later I found info on the web stating that it is difficult or
> impossible to  build with DEC C.  

That's been a long-standing problem with SOCKETSHR; it's fixed in
version 0.9D-4; see the above Web site for a pointer.

> The gzip and tar part of the install ran fine, leaving me with a large
> directory tree  starting with PERL5_004_01. I then pulled
> configure.com off the net, put it in the  [.vms] directory and ran it.
> It worked fine, but suggested that I use socketshr and  netlib. 

Configure.Com is still catching up with VMS 7.1, so it doesn't know
about the new socket options.  If you add a #define DECCRTL_SOCKETS
to [.vms]config.vms and remove SOCKETSHR from the SOCKLIB macro
in Descrip.MMS, you can build with the DECCRTL socket support
instead.

> Most of the documentation I was able to find seemed to indicate that
> skipping  socketshr would be fine as long as I edited sockadapt.h to
> get rid of the socketshr  references and add ucx references.  I tried
> this and most of the compiles were  successful except for a few data
> type mismatches. (That reminds me of another problem:  the MMK utility
> dies with an unknown error any time there are any warnings in a 
> compile or link.)

MMK is reporting the exit status of the program which originally
incurred the error.  However, since many of the tools involved in
the build (e.g. C compiler, linker) have their own message sets,
which aren't in the system message library, an attempt to resolve
one of their error status values to a message using the system
message library (e.g. by using EXIT or F$MESSAGE from DCL) usually
yields a NOMSG result.  Similarly, MMK's exit status refers to one
of its own messages (MMK__ERRUPD), so DCL commands don't know
about it.

> So, if anyone out there would be willing to suggest something or point
> me to some  decent documentation or even provide a VAX/VMS 7.0 PERL
> executable, please let me  know.  
>
> In my latest attempted build, I am now getting 
> 
> %LINK-W-MULDEF, symbol DECC$GETHOSTENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$SETHOSTENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$ENDHOSTENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$SETNETENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$ENDNETENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$GETSERVENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$SETSERVENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$ENDSERVENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$SETPROTOENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %LINK-W-MULDEF, symbol DECC$ENDPROTOENT multiply defined
>         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
> %MMK-F-ERRUPD, error status %X10648268 occurred when updating target MINIPERL.EXE

Hmm -- looks like you've got a DECCRTL which has these functions
implemented, so you can remove the stubs from sockadapt.c when
building with DECCRTL_SOCKETS.  If this doesn't solve your
problem, please send mail to me or the VMSPerl list
(vmsperl@genetics.upenn.edu), and we'll try to sort it out, and
then document the changes for other folks.

Thanks for the detailed report.

Regards,
Charles Bailey  bailey@genetics.upenn.edu