search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.93k stars 551 forks source link

Not OK: perl v5.7.0 +DEVEL7481 on VMS_AXP V7.1 (UNINSTALLED) #2785

Closed p5pRT closed 20 years ago

p5pRT commented 23 years ago

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

Searchable as RT4555$

p5pRT commented 23 years ago

From pvhp@forte.com

This was with the perl@​7483 kit​: the build was fine (no need to mess with vms/vms_yfix.pl)\, but there were two test failures​:

[.lib]st-lock...........FAILED on test 1

[.lib]vmsish............FAILED on test 14

Failed 2/254 tests\, 94.88% okay. u=24.58 s=0 cu=0 cs=0 files=243 tests=10482

Perl Info ``` Flags: category=install severity=none Site configuration information for perl v5.7.0: Configured by pvhp at Mon Oct 30 14:26:29 UTC-7:00 2000. Summary of my perl5 (revision 5.0 version 7 subversion undef) configuration: Platform: osname=VMS, osvers=V7.1, archname=VMS_AXP uname='VMS vale V7.1 AlphaServer 4100 5/300 2MB' config_args='-Dusedevel -des' hint=none, useposix=false, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='CC/DECC', ccflags ='/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList', optimize='', cppflags='undef' ccversion='60090001', gccversion='', gccosandvers='undef' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='int', lseeksize=4 alignbytes=8, usemymalloc=N, prototype=define Linker and Libraries: ld='Link', ldflags ='/NoTrace/NoMap' libpth=/sys$share /sys$library libs= perllibs= libc=(DECCRTL), so=exe, useshrplib=undef, libperl=undef Dynamic Linking: dlsrc=dl_vms.c, dlext=exe, d_dlsymun=undef, ccdlflags='' cccdlflags='', lddlflags='/Share' Locally applied patches: DEVEL7481 @INC for perl v5.7.0: 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 . Environment for perl v5.7.0: HOME=user:[pvhp] LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PERLSHR=PERL_ROOT:[000000]PERLSHR.EXE PERL_BADLANG (unset) PERL_ROOT=DKB100:[PERL5_005_03.] SHELL (unset) ```
p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

At 02​:58 PM 10/30/00 -0800\, Peter Prymmer wrote​: \

This was with the perl@​7483 kit​: the build was fine (no need to mess with vms/vms_yfix.pl)\, but there were two test failures​:

[.lib]st-lock...........FAILED on test 1

Peter\, does VMS have the same lack of functionality for file locking that DJGPP/DOS does (i.e.\, no working versions of flock or lockf or fcntl(...\,F_SETLK/W\,...))? If so\, look at the changes I helped put into both t/lib/st-lock.t and ext/Storable/Storable.pm for DJGPP. Essentially\, the changes made the locking versions of store/retrieve and the tests for them no-ops if ($^O eq 'dos'). If VMS has the same problem\, it would be easy to add VMS to those no-op tests.

HTH

Peter J. Farley III (pjfarley@​dorsai.org OR   pjfarley@​banet.net)

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Mon\, 30 Oct 2000\, Peter J. Farley III wrote​:

At 02​:58 PM 10/30/00 -0800\, Peter Prymmer wrote​: \

This was with the perl@​7483 kit​: the build was fine (no need to mess with vms/vms_yfix.pl)\, but there were two test failures​:

[.lib]st-lock...........FAILED on test 1

Peter\, does VMS have the same lack of functionality for file locking that DJGPP/DOS does (i.e.\, no working versions of flock or lockf or fcntl(...\,F_SETLK/W\,...))? If so\, look at the changes I helped put into both t/lib/st-lock.t and ext/Storable/Storable.pm for DJGPP. Essentially\, the changes made the locking versions of store/retrieve and the tests for them no-ops if ($^O eq 'dos'). If VMS has the same problem\, it would be easy to add VMS to those no-op tests.

HTH

Thanks. The real fix would appear to be set d_fcntl='undef' in VMS's config.sh. While there is an fcntl() routine in the RTL and there are *LOCK* constants\, one cannot use fcntl() for locking. The default for open files on VMS is that they are not shared. One has to pass certain non POSIX compliant extensions to fopen() in order to open a file for sharing on VMS. It's actually a mystery why the fcntl is so unhelpful in this regard.

Thanks for your tip. If mucking with configure.com does not do it\, I'll take a look at the dos methods.

Peter Prymmer

p5pRT commented 23 years ago

From @craigberry

At 7​:16 PM -0500 10/30/00\, Peter J. Farley III wrote​:

At 02​:58 PM 10/30/00 -0800\, Peter Prymmer wrote​: \

This was with the perl@​7483 kit​: the build was fine (no need to mess with vms/vms_yfix.pl)\, but there were two test failures​:

[.lib]st-lock...........FAILED on test 1

Peter\, does VMS have the same lack of functionality for file locking that DJGPP/DOS does (i.e.\, no working versions of flock or lockf or fcntl(...\,F_SETLK/W\,...))? If so\, look at the changes I helped put into both t/lib/st-lock.t and ext/Storable/Storable.pm for DJGPP. Essentially\, the changes made the locking versions of store/retrieve and the tests for them no-ops if ($^O eq 'dos'). If VMS has the same problem\, it would be easy to add VMS to those no-op tests.

Thanks for the tip; I'll try to take a look at Storable and see if omitting locking seems like the right thing to do for VMS.

My punishment for not getting a patch out yet is having to explain again how all this works on VMS. There's no flock() at all\, nor\, I believe lockf(). It usually doesn't matter because files are locked by default; if you want shared access you have specify it explicitly. fcntl() exists on some versions of the C RTL from the last two years or so\, but it doesn't do F_SETLK/W. It does have those defined in the header\, but it doesn't do anything with them\, thus fooling the test for them in pp_sys.c where it tries to see if fcntl() can emulate flock(). We should probably have something in configure.com that checks to see if (when fcntl exists) F_SETLK and F_SETLKW actually work and undef's them if not; this would make the test in pp_sys.c realize that fcntl() cannot emulate flock().

BTW\, I get "All tests successful" with perl@​7483 using DEC C V5.2-003 on OpenVMS Alpha V7.1. I do notice\, however\, that with perl -V its identity lags slightly behind​:

  Locally applied patches​:   DEVEL7481

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

At 04​:34 PM 10/30/00 -0800\, Peter Prymmer wrote​: \

Thanks. The real fix would appear to be set d_fcntl='undef' in VMS's config.sh. While there is an fcntl() routine in the RTL and there are *LOCK* constants\, one cannot use fcntl() for locking. The default for open files on VMS is that they are not shared. One has to pass certain non POSIX compliant extensions to fopen() in order to open a file for sharing on VMS. It's actually a mystery why the fcntl is so unhelpful in this regard.

We have the same situation in DJGPP. "fcntl" is in libc\, with some functions implemented and others (notably the locking ones) not implemented (ENOSYS)\, but all constants defined (for compatibility...).

FWIW\, DJGPP does *not* use d_fcntl='undef'\, and until Storable we got along just fine.

Thanks for your tip. If mucking with configure.com does not do it\, I'll take a look at the dos methods.

If your RTL has "lockf()"\, I think perl Configure will try to use that instead to emulate "flock"\, but then again I seem to remember that Configure tries to find "lockf()" first\, and only defaults to "fcntl" if it can't find "lockf". If I'm not going senile\, that is.

Good luck.

Peter J. Farley III (pjfarley@​dorsai.org OR   pjfarley@​banet.net)

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

At 07​:33 PM 10/30/00 -0600\, Craig A. Berry wrote​: \

Thanks for the tip; I'll try to take a look at Storable and see if omitting locking seems like the right thing to do for VMS.

Well\, the changes I contributed to Storable don't *eliminate* locking\, they just change Storable to Carp about it if you try to use "lock_store" or "lock_retrieve"\, and then return "undef". The "lock" tests are just bypassed if ($^O eq 'dos')\, with a message about broken fcntl/flock on our platform.

The rest of Storable was unchanged.

My punishment for not getting a patch out yet is having to explain again how all this works on VMS. There's no flock() at all\, nor\, I believe lockf(). It usually doesn't matter because files are locked by default; if you want shared access you have specify it explicitly.

fcntl() exists on some versions of the C RTL from the last two years or so\, but it doesn't do F_SETLK/W. It does have those defined in the header\, but it doesn't do anything with them\, thus fooling the test for them in pp_sys.c where it tries to see if fcntl() can emulate flock(). We should probably have something in configure.com that checks to see if (when fcntl exists) F_SETLK and F_SETLKW actually work and undef's them if not; this would make the test in pp_sys.c realize that fcntl() cannot emulate flock().

Yes\, but what will Configure do when it discovers it has no "flock" and no way to emulate it at all? Does it barf?

BTW\, sorry for replying to Peter P. before I read your $0.02 worth. Just ignore the useless stuff about "lockf" in my reply to him.

BTW\, I get "All tests successful" with perl@​7483 using DEC C V5.2-003

on OpenVMS Alpha V7.1. I do notice\, however\, that with perl -V its identity lags slightly behind​:

Locally applied patches​: DEVEL7481

Yes\, I noticed the same thing on DJGPP\, but since I'm so new here\, I assumed it was normal. Isn't it?

Peter J. Farley III (pjfarley@​dorsai.org OR   pjfarley@​banet.net)

p5pRT commented 23 years ago

From @craigberry

At 4​:34 PM -0800 10/30/00\, Peter Prymmer wrote​:

The real fix would appear to be set d_fcntl='undef' in VMS's config.sh.

Hmm. But fcntl() does exist in recent versions of the C RTL -- it just doesn't do locking\, as you point out. I'd rather have us tell the truth and code the tests to match. If we undef F_SETLK and F_SETLKW when they don't work (currently always) then we correctly signal that there is no flock() or emulation thereof but leave other fcntl() functionality intact.

It's actually a mystery why the fcntl is so unhelpful in this regard.

Indeed. I assume it's non-trivial or it would have been done by now.

In an asynchronous post on this thread the other Peter said​:

Yes\, but what will Configure do when it discovers it has no "flock" and no way to emulate it at all? Does it barf?

I think it can handle the case where there's no emulation\, but even if it can't\, the truth hurts sometimes and it should learn to deal with it :-).

p5pRT commented 23 years ago

From @doughera88

On Mon\, 30 Oct 2000\, Craig A. Berry wrote​:

At 4​:34 PM -0800 10/30/00\, Peter Prymmer wrote​:

The real fix would appear to be set d_fcntl='undef' in VMS's config.sh.

Hmm. But fcntl() does exist in recent versions of the C RTL -- it just doesn't do locking\, as you point out. I'd rather have us tell the truth and code the tests to match. If we undef F_SETLK and F_SETLKW when they don't work (currently always) then we correctly signal that there is no flock() or emulation thereof but leave other fcntl() functionality intact.

Hmm. Sounds like we need a d_fcntl_can_lock Configure variable. Then VMS and DOS/DJGPP could set that to undef.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Tue\, 31 Oct 2000\, Andy Dougherty wrote​:

Hmm. Sounds like we need a d_fcntl_can_lock Configure variable. Then VMS and DOS/DJGPP could set that to undef.

I like that idea very much. In a test I did a few weeks ago I could get vmsperl to pass all tests with d_fcntl artificially set to 'undef'\, but as Craig points out this precludes the other possible uses of fcntl(). A new $d_fcntl_can_lock Configure variable would help quite a bit here.

Peter Prymmer

p5pRT commented 23 years ago

From @craigberry

At 10​:21 AM 10/31/2000 -0800\, Peter Prymmer wrote​:

On Tue\, 31 Oct 2000\, Andy Dougherty wrote​:

Hmm. Sounds like we need a d_fcntl_can_lock Configure variable. Then VMS and DOS/DJGPP could set that to undef.

I like that idea very much.

Me too. That's why I suggested it at​:

\<http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-10/msg00817.html>

So\, what happens first? I'm afraid I know very little about how Configure works on non-VMS platforms. _______________________________________________ Craig A. Berry
mailto​:craig.berry@​psinetcs.com

p5pRT commented 23 years ago

From @jhi

So\, what happens first?

I pour myself a cup of strong coffee. :-)

I'm afraid I know very little about how Configure works on non-VMS platforms.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

At 09​:15 PM 10/31/00 -0500\, Andy Dougherty wrote​: \

I'll try to get around to handling the Configure end with at least a dummy test in the next couple of days. Feel free to remind me if I don't actually get around to it.

Andy\, just a note about fcntl and DOS/DJGPP​: I am actively working with the djgpp-workers group to implement these locking functions. I have no idea how the timing will work out (as in\, I don't know how soon I'll actually get something working)\, but my hope is that some future release of perl for DOS/DJGPP *will* have file locking functionality.

I guess what I'm trying to say is\, don't worry *too* much about including DOS/DJGPP in the Configure changes\, unless it turns out to be easy to do.

OTOH\, if it makes future file-locking bypass/workarounds easier to put in while DOS/DJGPP is still without these functions\, I'm definitely in your debt.

Peter

Peter J. Farley III (pjfarley@​dorsai.org OR   pjfarley@​banet.net)

p5pRT commented 23 years ago

From The RT System itself

Duplicate of 20001016.015