not OK: 6620 on OpenVMS

[p5pRT]

Migrated from rt.perl.org#3700 (status was 'resolved')

Searchable as RT3700$

[p5pRT]

From pvhp@forte.com

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/Define=PERL _CORE MG.C

int ^ %CC-W-MISSINGRETURN\, Non-void function "Perl_magic_regdatum_set" does not contai n a return statement. at line number 382 in file DKB100​:[PERL]MG.C;1 %MMS-F-ABORT\, For target MG.OBJ\, CLI returned abort status​: %X10B91260.

And the VMS build stops dead there. Here by the way\, is what is seen on Tr64 Unix 4.0D​:

`sh cflags libperl.so mg.o` mg.c   CCCMD = cc -DPERL_CORE -c -std -fprm d -ieee -D_INTRINSICS -I/usr/lo cc​: Warning​: mg.c\, line 382​: Non-void function "Perl_magic_regdatum_set" does n. int ^

But with that T64 compiler it is a warning that does not abort the (GNU) make.

I see that Perl_magic_regdatum_set() was not in 6612\, but that it is now mentioned in proto.h (int prototype)\, embed.h\, and perl.h in addition to mg.c. If Perl_magic_regdatum_set() cannot be retyped to void then the following bletcherous hack can enable the build to proceed with DEC C V6.0-001 on OpenVMS Alpha V7.1​:

Inline Patch

```diff --- mg.c.orig Mon Aug 14 07:36:27 2000 +++ mg.c Tue Aug 15 10:58:35 2000 @@ -384,6 +384,9 @@ { dTHR; Perl_croak(aTHX_ PL_no_modify); +#ifdef VMS + return(0); +#endif } U32 ```

End of Hack.

Suggestions about a proper fix would be welcome.

With that patch `mms test` returns​:

[.lib]cgi-html..........FAILED on test 9

[.lib]ftmp-mktemp.......FAILED on test 5 [.lib]ftmp-posix........FAILED on test 4
[.lib]ftmp-security.....ok [.lib]ftmp-tempfile.....FAILED on test 4

[.pod]find..............FAILED on test 2

I'll see if I can address some of those later.

By the way on Tru64 I saw​:

All tests successful. u=0.7 s=1.11667 cu=98.7 cs=35.1 scripts=246 tests=11136

Peter Prymmer

[p5pRT]

From @jhi

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/Define=PERL _CORE MG.C

int ^ %CC-W-MISSINGRETURN\, Non-void function "Perl_magic_regdatum_set" does not contai n a return statement. at line number 382 in file DKB100​:[PERL]MG.C;1 %MMS-F-ABORT\, For target MG.OBJ\, CLI returned abort status​: %X10B91260.

And the VMS build stops dead there. Here by the way\, is what is seen on Tr64 Unix 4.0D​:

`sh cflags libperl.so mg.o` mg.c CCCMD = cc -DPERL_CORE -c -std -fprm d -ieee -D_INTRINSICS -I/usr/lo cc​: Warning​: mg.c\, line 382​: Non-void function "Perl_magic_regdatum_set" does n. int ^

But with that T64 compiler it is a warning that does not abort the (GNU) make.

I see that Perl_magic_regdatum_set() was not in 6612\, but that it is now mentioned in proto.h (int prototype)\, embed.h\, and perl.h in addition to mg.c. If Perl_magic_regdatum_set() cannot be retyped to void then the following bletcherous hack can enable the build to proceed with DEC C V6.0-001 on OpenVMS Alpha V7.1​:

--- mg.c.orig Mon Aug 14 07​:36​:27 2000 +++ mg.c Tue Aug 15 10​:58​:35 2000 @​@​ -384\,6 +384\,9 @​@​ { dTHR; Perl_croak(aTHX_ PL_no_modify); +#ifdef VMS + return(0); +#endif }

U32 End of Hack.

Suggestions about a proper fix would be welcome.

With that patch `mms test` returns​:

[.lib]cgi-html..........FAILED on test 9

[.lib]ftmp-mktemp.......FAILED on test 5 [.lib]ftmp-posix........FAILED on test 4
[.lib]ftmp-security.....ok [.lib]ftmp-tempfile.....FAILED on test 4

[.pod]find..............FAILED on test 2

I'll see if I can address some of those later.

By the way on Tru64 I saw​:

All tests successful. u=0.7 s=1.11667 cu=98.7 cs=35.1 scripts=246 tests=11136

Peter Prymmer

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

Cool. Thanks.

Peter Prymmer

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

Cool. Thanks.

The 6640 also has a newer File​::Temp.

The CGI failure is surprising.

Actually it appears to be the same problem we saw just recently​: CGI.pm is set up to put a "\n" on VMS because a carriage return automatically gets inserted into the output stream when writing records to a webserver "socket" (so my question is "Were we running this test before?" or "Why didn't this turn up before?"). The tests are not set up to accomodate that\, hence​:

not ok 9 header() not ok 10 header() not ok 11 header() not ok 12 header()

Here is a patch to cgi-html.t that checks out OK on VMS and Tru64​:

Inline Patch

```diff --- t/lib/cgi-html.t.orig Sun Aug 13 11:36:38 2000 +++ t/lib/cgi-html.t Tue Aug 15 11:33:43 2000 @@ -37,10 +37,17 @@ local($") = '-'; test(8,h1('fred','agnes','maura') eq '

fred-agnes-maura

',"open/close tag \$\" interpolation"); } -test(9,header() eq "Content-Type: text/html; charset=ISO-8859-1\015\012\015\012","header()"); -test(10,header(-type=>'image/gif') eq "Content-Type: image/gif\015\012\015\012","header()"); -test(11,header(-type=>'image/gif',-status=>'500 Sucks') eq "Status: 500 Sucks\015\012Content-Type: image/gif\015\012\015\012","header()"); -test(12,header(-nph=>1) eq "HTTP/1.0 200 OK\015\012Content-Type: text/html; charset=ISO-8859-1\015\012\015\012","header()"); +my $CRLF = "\015\012"; +if ($^O eq 'VMS') { + $CRLF = "\n"; # only on a webserver does a \r get inserted +} +if (ord("\t") != 9) { + $CRLF = "\r\n"; # EBCDIC CRLF +} +test(9,header() eq "Content-Type: text/html; charset=ISO-8859-1$CRLF$CRLF","header()"); +test(10,header(-type=>'image/gif') eq "Content-Type: image/gif$CRLF$CRLF","header()"); +test(11,header(-type=>'image/gif',-status=>'500 Sucks') eq "Status: 500 Sucks${CRLF}Content-Type: image/gif$CRLF$CRLF","header()"); +test(12,header(-nph=>1) eq "HTTP/1.0 200 OK${CRLF}Content-Type: text/html; charset=ISO-8859-1$CRLF$CRLF","header()"); test(13,start_html() ."\n" eq <

End of Patch.

Peter Prymmer

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

Unfortunately it does not quite go far enough since we now obtain a pointer mismatch error since MEMBER_TO_FPTR is expecting an int​:

CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList /Define=PERL_CORE GLOBALS.C

  MEMBER_TO_FPTR(Perl_magic_regdatum_set)\, 0\, 0\, 0}; ...............................^ %CC-W-PTRMISMATCH\, In the initializer for PL_vtbl_regdatum.svt_set\, the referenced type of the pointer value "Perl_magic_regdatum_set" is "function (pointer to struct sv\, pointer to struct magic) returning void"\, which is not compatible with "function (pointer to struct sv\, pointer to struct magic) returning int". at line number 2856 in file DKB100​:[PERL]PERL.H;1 %MMS-F-ABORT\, For target GLOBALS.OBJ\, CLI returned abort status​: %X10B91260.

If I alter perl.h to have​:

# define MEMBER_TO_VPTR(name) (void)name

then​:

#ifdef VMS EXT MGVTBL PL_vtbl_regdatum = {MEMBER_TO_FPTR(Perl_magic_regdatum_get)\,   MEMBER_TO_VPTR(Perl_magic_regdatum_set)\, 0\, 0 \, 0}; #else EXT MGVTBL PL_vtbl_regdatum = {MEMBER_TO_FPTR(Perl_magic_regdatum_get)\,   MEMBER_TO_FPTR(Perl_magic_regdatum_set)\, 0\,0\, 0}; #endif

Then the compiler complains that the types are OK but that I need to have an int rather than a void in an array initialization. 6640 will not build yet on VMS.

Peter Prymmer

[p5pRT]

From @jhi

On Tue\, Aug 15\, 2000 at 02​:13​:34PM -0700\, Peter Prymmer wrote​:

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

Unfortunately it does not quite go far enough since we now obtain a pointer mismatch error since MEMBER_TO_FPTR is expecting an int​:

You are right. Sarathy already fixed this The Right Way. Hang on.

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 02​:13​:34PM -0700\, Peter Prymmer wrote​:

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

Unfortunately it does not quite go far enough since we now obtain a pointer mismatch error since MEMBER_TO_FPTR is expecting an int​:

You are right. Sarathy already fixed this The Right Way. Hang on.

OK. For what it is worth if I revert to the int type for the new function in mg.c (and the prototype in proto.h) then I can compile miniperl\, but we seem to have introduced an XS file dependency unique to VMS now since the perl build now fails with​:

MCR Sys$Disk​:[]miniperl.exe "-I[.lib]" [.EXT.DYNALOADER]DYNALOADER_PM.PL %RENAME-I-RENAMED\, DKB100​:[PERL]DYNALOADER.PM;1 renamed to DKB100​:[PERL.EXT.DYNALOADER]DYNALOADER.PM;1 Copy/Log/NoConfirm [.ext.dynaloader]dynaloader.pm [.lib]DynaLoader.pm %COPY-S-COPIED\, DKB100​:[PERL.EXT.DYNALOADER]DYNALOADER.PM;1 copied to DKB100​:[PERL.LIB]DYNALOADER.PM;1 (54 blocks) Can't locate VMS/Filespec.pm in @​INC (@​INC contains​: lib/VMS_AXP lib perl_root​:[lib.VMS_AXP.5_7_0] perl_root​:[lib] perl_root​:[lib.site_perl.VMS_AXP] perl_root​:[lib.site_perl] /perl_root/lib/site_perl .) at lib/File/Spec/VMS.pm line 13. BEGIN failed--compilation aborted at lib/File/Spec/VMS.pm line 13. Compilation failed in require at lib/File/Spec.pm line 14. Compilation failed in require at lib/File/Spec/Functions.pm line 3. BEGIN failed--compilation aborted at lib/File/Spec/Functions.pm line 3. Compilation failed in require at lib/AutoSplit.pm line 9. BEGIN failed--compilation aborted at lib/AutoSplit.pm line 9. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. %RMS-E-FNF\, file not found %MMS-F-ABORT\, For target [.LIB]DYNALOADER.PM\, CLI returned abort status​: %X00018 292. -RMS-E-FNF\, file not found

I think that Tim's latest patch did employ VMS​::Filespec in it (?)\, but it looks like we now have a bootstrapping problem.

Peter Prymmer

[p5pRT]

From @jhi

On Tue\, Aug 15\, 2000 at 02​:29​:34PM -0700\, Peter Prymmer wrote​:

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 02​:13​:34PM -0700\, Peter Prymmer wrote​:

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

Unfortunately it does not quite go far enough since we now obtain a pointer mismatch error since MEMBER_TO_FPTR is expecting an int​:

You are right. Sarathy already fixed this The Right Way. Hang on.

OK. For what it is worth if I revert to the int type for the new function in mg.c (and the prototype in proto.h) then I can compile miniperl\, but we seem to have introduced an XS file dependency unique

Okay\, good.

to VMS now since the perl build now fails with​:

MCR Sys$Disk​:[]miniperl.exe "-I[.lib]" [.EXT.DYNALOADER]DYNALOADER_PM.PL

Hmmm. Would adding -I[.ext] help any?

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 02​:29​:34PM -0700\, Peter Prymmer wrote​:

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 02​:13​:34PM -0700\, Peter Prymmer wrote​:

On Tue\, 15 Aug 2000\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 15\, 2000 at 11​:08​:40AM -0700\, Peter Prymmer wrote​:

On VMS the 6620 kit fails to build out of the box owing to a "missing" return() from the brand new Perl_magic_regdatum_set() function in mg.c​:

That's why there's 6640 with a void Perl_magic_regdatum_set().

Unfortunately it does not quite go far enough since we now obtain a pointer mismatch error since MEMBER_TO_FPTR is expecting an int​:

You are right. Sarathy already fixed this The Right Way. Hang on.

OK. For what it is worth if I revert to the int type for the new function in mg.c (and the prototype in proto.h) then I can compile miniperl\, but we seem to have introduced an XS file dependency unique

Okay\, good.

to VMS now since the perl build now fails with​:

MCR Sys$Disk​:[]miniperl.exe "-I[.lib]" [.EXT.DYNALOADER]DYNALOADER_PM.PL

Hmmm. Would adding -I[.ext] help any?

It might\, but I don't think that it is dieing at that point\, rather on the AutoSplit of DynaLoader (which is what might benefit from adding "-I[.ext]"). I'm still muddling with it though. I think my previous speculation about Tim's patch having had an effect here was misplaced since this is an Autosplit DynaLoader problem and does not invoke File​::Temp AFAIK.

Peter Prymmer

[p5pRT]

From @craigberry

At 02​:29 PM 8/15/2000 -0700\, Peter Prymmer wrote​:

Can't locate VMS/Filespec.pm in @​INC (@​INC contains​: lib/VMS_AXP lib

[snip]

%RMS-E-FNF\, file not found %MMS-F-ABORT\, For target [.LIB]DYNALOADER.PM\, CLI returned abort status​: %X00018 292. -RMS-E-FNF\, file not found

I'm pretty sure this is something I've been seeing occasionally in all recent development kits. It may have to do with the ordering of the LIBPREREQ target in descrip_mms.template since Dynaloader depends on VMS​::Filespec but comes before it in the list. As a workaround you can try explicitly building the [.lib.VMS]Filespec.pm target\, then rebuild the whole thing and see if that took care of it. I haven't posted before since I'm not sure yet whether we should reorder LIBPREREQ (possibly just shuffling the problem elsewhere) or add a new dependency for Dynaloader/Filespec.

FWIW\, I only saw the problem on a VMS 7.2-1 system but not on a 7.1 system\, both using MMK. This was back around 6429 or so. _______________________________________________ Craig A. Berry
mailto​:craig.berry@​metamorgs.com

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, 15 Aug 2000\, Craig A. Berry wrote​:

At 02​:29 PM 8/15/2000 -0700\, Peter Prymmer wrote​:

Can't locate VMS/Filespec.pm in @​INC (@​INC contains​: lib/VMS_AXP lib

[snip]

%RMS-E-FNF\, file not found %MMS-F-ABORT\, For target [.LIB]DYNALOADER.PM\, CLI returned abort status​: %X00018 292. -RMS-E-FNF\, file not found

I'm pretty sure this is something I've been seeing occasionally in all recent development kits. It may have to do with the ordering of the LIBPREREQ target in descrip_mms.template since Dynaloader depends on VMS​::Filespec but comes before it in the list. As a workaround you can try explicitly building the [.lib.VMS]Filespec.pm target\, then rebuild the whole thing and see if that took care of it. I haven't posted before since I'm not sure yet whether we should reorder LIBPREREQ (possibly just shuffling the problem elsewhere) or add a new dependency for Dynaloader/Filespec.

FWIW\, I only saw the problem on a VMS 7.2-1 system but not on a 7.1 system\, both using MMK. This was back around 6429 or so.

Bingo. In fact I am working on a patch for this right now. I am glad to hear that MMK encounters a similar fate. After I get a successful build (knock on wood) I'll post a patch to vms/descrip_mms.template.

Peter Prymmer

[p5pRT]

From [Unknown Contact. See original ticket]

Peter Prymmer \pvhp@​forte\.com wrote​:		miniperl\, but we seem to have introduced an XS file dependency unique	to VMS now since the perl build now fails with​:
MCR Sys$Disk​:[]miniperl.exe "-I[.lib]" [.EXT.DYNALOADER]DYNALOADER_PM.PL
%RENAME-I-RENAMED\, DKB100​:[PERL]DYNALOADER.PM;1 renamed to
DKB100​:[PERL.EXT.DYNALOADER]DYNALOADER.PM;1
Copy/Log/NoConfirm [.ext.dynaloader]dynaloader.pm [.lib]DynaLoader.pm
%COPY-S-COPIED\, DKB100​:[PERL.EXT.DYNALOADER]DYNALOADER.PM;1 copied to
DKB100​:[PERL.LIB]DYNALOADER.PM;1 (54 blocks)
Can't locate VMS/Filespec.pm in @​INC (@​INC contains​: lib/VMS_AXP lib

I'd bet that someone put in a C\<require VMS​::Filespec> into File​::Spec​::VMS. In order to avoid such bootstrap problems\, all of the VMS​::Filespec routines are available in VMS perl without including [.VMS]Filespec.pm; one just needs to use the fully qualified names.

Regards\, Charles Bailey \bailey@&#8203;newman\.upenn\.edu

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, 16 Aug 2000\, Charles Bailey wrote​:

| Can't locate VMS/Filespec.pm in @​INC (@​INC contains​: lib/VMS_AXP lib

I'd bet that someone put in a C\<require VMS​::Filespec> into File​::Spec​::VMS. In order to avoid such bootstrap problems\, all of the VMS​::Filespec routines are available in VMS perl without including [.VMS]Filespec.pm; one just needs to use the fully qualified names.

Yes it appears that way​:

$ search [.lib.file.spec]vms.pm use use strict; use vars qw(@​ISA $VERSION); use Cwd; use File​::Basename; use VMS​::Filespec; Use VMS syntax when converting filespecs.   # Note​: we use '/' to glue things together here\, then let canonpath() Use VMS syntax when converting filespecs.

But the workaround of putting [.vms]filespec.pm fairly early in the LIBPREREQ macro seems to have done the trick of bootstrapping as far as we need it done for the build (only configpm goes ahead of [.vms]filespec.pm now).

Peter Prymmer

[p5pRT]

From [Unknown Contact. See original ticket]

Jarkko Hietaniemi \jhi@&#8203;iki\.fi wrote

On Tue\, Aug 15\, 2000 at 02​:13​:34PM -0700\, Peter Prymmer wrote​:

Unfortunately it does not quite go far enough since we now obtain a pointer mismatch error since MEMBER_TO_FPTR is expecting an int​:

You are right. Sarathy already fixed this The Right Way. Hang on.

I assume by The Right Way you mean inserting the 'return(0)' ?

I made the prototype by naively copying from Perl_regdatum_set\, since I didn't understand what was meant to be going on.

I note that the result from a magic subroutine is never used. So why are they all typed as 'int' rather than 'void' ?

Mike Guy

[p5pRT]

From @gsar

On Thu\, 17 Aug 2000 17​:03​:01 BST\, Mike Guy wrote​:

I note that the result from a magic subroutine is never used. So why are they all typed as 'int' rather than 'void' ?

The return value from some _are_ used (like svt_len). It _could_ be used for the others in future.

Sarathy gsar@​ActiveState.com