Open p5pRT opened 11 years ago
On VMS\, if I run configure.com as
@configure "-des" "-Dusedevel" "-Dusevmsdebug"
then it will tell me to invoke mmk as
mmk "/macro=(__DEBUG__)"
This works.
However\, if I invoke mmk as just mmk it doesn't. The build gets a log way\, then fails like this:
running PTAC$DKA0:[NCLARK.I.perl5191]MINIPERL.EXE;1 "-I[--.lib]" "ppport_h.PL" installing ppport.h for cpan/DB_File installing ppport.h for cpan/IPC-SysV installing ppport.h for cpan/List-Util installing ppport.h for cpan/Time-HiRes installing ppport.h for cpan/Win32API-File installing ppport.h for dist/Cwd removing temporary file PPPort.pm removing temporary file ppport.h MCR Sys$Disk:[]miniperl.exe "-I[.lib]" "-I[.dist.Cwd]" "-I[.dist.Cwd.lib]" make_ ext.pl "MAKE=MMK" "--dynamic" "--static" Making Cwd (all)
Creating Makefile.PL in dist/Cwd for Cwd
Running Makefile.PL in dist/Cwd PTAC$DKA0:[NCLARK.I.perl5191]MINIPERL.EXE;1 "-I../../lib" "Makefile.PL" "INST_LI B=[--.lib]" "INST_ARCHLIB=[--.lib]" "PERL_CORE=1" Writing Descrip.MMS for Cwd Making all in dist/Cwd MMK all /DESCRIPTION=descrip.mms /MACRO=("PERL_CORE=1") cp [.lib.File.Spec]Mac.pm [--.lib.File.Spec]Mac.pm cp [.lib.File.Spec]Cygwin.pm [--.lib.File.Spec]Cygwin.pm cp [.lib.File]Spec.pm [--.lib.File]Spec.pm cp [.lib.File.Spec]Unix.pm [--.lib.File.Spec]Unix.pm cp [.lib.File.Spec]OS2.pm [--.lib.File.Spec]OS2.pm cp [.lib.File.Spec]Win32.pm [--.lib.File.Spec]Win32.pm cp [.lib.File.Spec]Functions.pm [--.lib.File.Spec]Functions.pm cp [.lib.File.Spec]VMS.pm [--.lib.File.Spec]VMS.pm cp [.lib.File.Spec]Epoc.pm [--.lib.File.Spec]Epoc.pm cp cwd.pm [--.lib]cwd.pm MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" -e "use ExtUtils::Mksymlists;" -e "Mksymlists('NAME' => 'Cwd'\, 'DL_FUNCS' => { }\, 'DL_VARS' => []\, 'FUNCLIST' => [])" MCR [--]miniperl.exe -e "print ""[--.lib.auto.Cwd]Cwd.olb/Include=Cwd\n[--.lib.a uto.Cwd]Cwd.olb/Library\n"";" >>CWD.OPT MCR [--]miniperl.exe -e "print qq{DBGPerlShr/Share\n}" >>CWD.OPT MCR PTAC$DKA0:[NCLARK.I.perl5191]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUt ils::Command" -e "cp" "--" CWD.OPT [--.LIB.AUTO.CWD]CWD.OPT MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" [--.lib.ExtUtils]xsubpp -nolinen umbers -typemap [--.lib.ExtUtils]typemap CWD.xs >CWD.C CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/floa t=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(_USE_STD_STAT=1\,"VERSION=""3.41"""\, "XS_VERSION=""3.41""")/Include=([--])/List/Debug/NoOpt CWD.c If F$Search("[--.LIB.AUTO.CWD]CWD.OLB").eqs."" Then Library/Object/Create [--.LI B.AUTO.CWD]CWD.OLB Library/Object/Replace [--.LIB.AUTO.CWD]CWD.OLB CWD.OBJ %MMK-F-CANTUPD\, cannot update target [--]DBGPERLSHR.EXE - sources unknown %MMK-F-CANTUPD\, cannot update target [--]DBGPERLSHR.EXE - sources unknown Unsuccessful make(dist/Cwd): code=1024 at make_ext.pl line 490. %NONAME-F-NOMSG\, Message number 0C14805C %MMK-F-ERRUPD\, error status %X0C14805C occurred when updating target DYNEXT
The DESCRIP.MMS generated by @configure "-des" "-Dusedevel" "-Dusevmsdebug" is identical to that from @configure "-des" "-Dusedevel"
So\, why is it that the former's build doesn't work without mmk "/macro=(__DEBUG__)"?
(I'm guessing something in config.sh)
And if it's not sensible to make it work without the "/macro=(__DEBUG__)"\, then would it be better to generate a different DESCRIP.MMS that implicitly adds __DEBUG__\, and save the user having to type something that's actually mandatory?
This is blead somewhat more recent than v5.19.1\, but I don't know the commit offhand\, and I don't know the VMS equivalent of ./myconfig (On the HP Opensource Itanium)
Nicholas Clark
On Wed\, Jun 12\, 2013 at 10:44 AM\, Nicholas Clark \perlbug\-followup@​perl\.orgwrote:
# New Ticket Created by Nicholas Clark # Please include the string: [perl #118447] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118447 >
On VMS\, if I run configure.com as
@​configure "\-des" "\-Dusedevel" "\-Dusevmsdebug"
then it will tell me to invoke mmk as
mmk "/macro=\(\_\_DEBUG\_\_\)"
This works.
However\, if I invoke mmk as just mmk it doesn't. The build gets a log way\, then fails like this:
\
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/floa
t=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(_USE_STD_STAT=1\,"VERSION=""3.41"""\, "XS_VERSION=""3.41""")/Include=([--])/List/Debug/NoOpt CWD.c If F$Search("[--.LIB.AUTO.CWD]CWD.OLB").eqs."" Then Library/Object/Create [--.LI B.AUTO.CWD]CWD.OLB Library/Object/Replace [--.LIB.AUTO.CWD]CWD.OLB CWD.OBJ %MMK-F-CANTUPD\, cannot update target [--]DBGPERLSHR.EXE - sources unknown %MMK-F-CANTUPD\, cannot update target [--]DBGPERLSHR.EXE - sources unknown Unsuccessful make(dist/Cwd): code=1024 at make_ext.pl line 490. %NONAME-F-NOMSG\, Message number 0C14805C %MMK-F-ERRUPD\, error status %X0C14805C occurred when updating target DYNEXT
The DESCRIP.MMS generated by @configure "-des" "-Dusedevel" "-Dusevmsdebug" is identical to that from @configure "-des" "-Dusedevel"
So\, why is it that the former's build doesn't work without mmk "/macro=(__DEBUG__)"?
Technically it is not the top-level descrip.mms that has trouble but the descrip.mms generated for the extension build.
(I'm guessing something in config.sh)
Yes\, specifically the usevmsdebug='define' in config.sh that is telling EUMM to generate a descrip.mms for the extension that looks for a differently-named debug shareable image to link against.
And if it's not sensible to make it work without the "/macro=(__DEBUG__)"\, then would it be better to generate a different DESCRIP.MMS that implicitly adds __DEBUG__\, and save the user having to type something that's actually mandatory?
I think what happened is that the debug option was originally a command-line macro and was completely independent of the configuration process. Then someone noticed that the debug compile and link flags were not getting propagated to extension builds\, so the configuration option and EUMM changes were made to accomplish that. But without changing the way the top-level descrip.mms finds out what kind of build is being requested. And that all probably happened in the last century and I've never bothered to change it.
But I can't really think of any good reason to leave it as is and it should be an easy change to add one more symbol expansion the configuration process. I'll look into it soonish.
This is blead somewhat more recent than v5.19.1\, but I don't know the commit offhand\, and I don't know the VMS equivalent of ./myconfig (On the HP Opensource Itanium)
$ mcr []miniperl -"Ilib" -"V"
or
$ [.vms]myconfig.com
should do the trick (though the latter is very stale based on its comments).
And once you get your debug perl built\, you'll get to deal with a debugging environment that\, like everything else on VMS\, is completely different even when similar in principle to whatever else you're used to\, so you may need the manual at:
\<http://h71000.www7.hp.com/doc/84final/4538/ba554_90016.pdf>
and I'll be happy to put together a cheat sheet if you give me an idea of what you're doing\, e.g.\, what you want to break on\, etc.
The RT System itself - Status changed from 'new' to 'open'
On Wed\, Jun 12\, 2013 at 12:42 PM\, Craig A. Berry \craig\.a\.berry@​gmail\.comwrote:
But I can't really think of any good reason to leave it as is and it should be an easy change to add one more symbol expansion the configuration process. I'll look into it soonish.
Done as of \< http://perl5.git.perl.org/perl.git/commitdiff/9152021db0fe677bcc7f8460e5d5419a79462abc
.
On Wed\, Jun 12\, 2013 at 12:42:45PM -0500\, Craig A. Berry wrote:
But I can't really think of any good reason to leave it as is and it should be an easy change to add one more symbol expansion the configuration process. I'll look into it soonish.
Thanks. I see that you did this with commit 9152021db0fe677b. But that commit didn't remove the various __DEBUG__ sections from the template. Is that correct - ie is there still a reason/use for invoking mmk with /MACRO=__DEBUG__ ?
This is blead somewhat more recent than v5.19.1\, but I don't know the commit offhand\, and I don't know the VMS equivalent of ./myconfig (On the HP Opensource Itanium)
$ mcr []miniperl -"Ilib" -"V"
or
$ [.vms]myconfig.com
should do the trick (though the latter is very stale based on its comments).
ah OK thanks.
And once you get your debug perl built\, you'll get to deal with a debugging environment that\, like everything else on VMS\, is completely different even when similar in principle to whatever else you're used to\, so you may need the manual at:
\<http://h71000.www7.hp.com/doc/84final/4538/ba554_90016.pdf>
and I'll be happy to put together a cheat sheet if you give me an idea of what you're doing\, e.g.\, what you want to break on\, etc.
I wasn't trying to debug the C code on VMS. I was trying to *not* break the build while refactoring how and when lib/sitecustomize.pl got built. In the process of which I discovered that there seemed to be two rules to build MINIPERL.EXE.
I think that I got it all straight as I merged it to blead. (And as Sprout discovered\, I inadvertently made the Unix build very fragile if you break miniperl early enough. Oops. Had that happen to me too before\, and it's not fun)
This was all related to untwisting the build to get Zefram's File::Spec in XS bootstrapping. Which it should do. But in the process I noticed that there is still vms/ext
Is it OK to remove the +x from vms/ext/filespec.t? And to move it and Filespec.pm into ext/vms?
It's all in the branch smoke-me/nicholas/vms-filespec (which also depends on the Configure patch to add nonxs_ext to known_extensions).
It works for me on the VMS testdrive system\, and all the smokers seem happy with it.
I'm not sure what "cheatsheet" I'd benefit from :-) I'm still having "problems" with rm -rf In that
* I can run rm -rf from bash but it doesn't delete files which are read-only (I believe because of the mapping of Unix rwx 3-way permissions to the VMS 4-way permissions including delete) * I can use the installed perl 5.8.6 with File::Path to rmtree\, which does know how to delete read-only files\, but in turn *that* doesn't cope with multiple dots in filenames * xargs in the GNV bash SEGVs. As does using -exec in find * the GNV bash won't read commands from a pipe
but with some combination of the above\, sed and temporary files\, I can actually delete stuff.
I did have a counter-cheat sheet:
1) this makes a tarball named after the current revision:
commit=`git rev-parse --short=12 HEAD`; tar cf perl-$commit.tar --files-from \<(sed -e 's/[ ].*//' MANIFEST) --transform 's!^!perl-'$commit'/!'
(requires GNU tar\, which I think *BSD and OS X also ship. There's a literal tab in there)
2) Putty's scp is excellent\, as it speaks the sftp protocol and hence works with the SSH2 based server on VMS
I don't think I said - I saw Simon Tatham a while back and said thanks for putty\, as it was really useful for (of all things) VMS. And he initially guessed wrongly as to why. He assumed that I was finding its terminal emulation excellent. He said that before he retired\, his father worked with VMS systems\, and so was one of the early Putty users and testers\, with the result that the VMS specific stuff got a lot of feedback. :-)
Nicholas Clark
On Wed\, Jun 19\, 2013 at 10:07 AM\, Nicholas Clark \nick@​ccl4\.org wrote:
On Wed\, Jun 12\, 2013 at 12:42:45PM -0500\, Craig A. Berry wrote:
But I can't really think of any good reason to leave it as is and it should be an easy change to add one more symbol expansion the configuration process. I'll look into it soonish.
Thanks. I see that you did this with commit 9152021db0fe677b. But that commit didn't remove the various __DEBUG__ sections from the template. Is that correct -
Yes.
ie is there still a reason/use for invoking mmk with /MACRO=__DEBUG__ ?
No.
What I changed is that the new line in vms/descrip_mms.template that looks like ~USEVMSDEBUG~ is now replaced by one of two things when configure.com translates the template into the top-level descrip.mms. If you have *not* configured with -Dusevmsdebug\, it gets replaced by a blank line. If you *have* configured with -Dusevmsdebug\, it gets replaced with __DEBUG__=1.
So the macro gets defined (or not) based on how you configure and there is no longer any reason to specify it on the command line. The things that *reference* the macro are still necessary to produce a debug build.
Is it OK to remove the +x from vms/ext/filespec.t?
Should be.
And to move it and Filespec.pm into ext/vms?
This is potentially dodgy because you can't run a Makefile.PL without it\, but I think you covered that by putting the new location in buildcustomize.pl\, so as long as we're running miniperl it should be ok.
I'm not sure what "cheatsheet" I'd benefit from :-) I'm still having "problems" with rm -rf
I think the system you are using is at VMS v8.4\, which means you should be able to do (from DCL):
$ delete/tree [.perl-\<commit-id>...]*.*;*
where \<commit-id> is replaced with the actual name that is part of the top-level directory you are trying to delete.
I did have a counter-cheat sheet:
1) this makes a tarball named after the current revision:
commit=`git rev-parse --short=12 HEAD`; tar cf perl-$commit.tar --files-from \<(sed -e 's/[ ].*//' MANIFEST) --transform 's!^!perl-'$commit'/!'
I would think git archive would be easier but I'm probably missing some part of your intent.
2) Putty's scp is excellent\, as it speaks the sftp protocol and hence works with the SSH2 based server on VMS
Indeed. Since you made me aware of it\, I regularly use pscp from OS X and Windows to exchange files with VMS systems.
I don't think I said - I saw Simon Tatham a while back and said thanks for putty\, as it was really useful for (of all things) VMS. And he initially guessed wrongly as to why. He assumed that I was finding its terminal emulation excellent. He said that before he retired\, his father worked with VMS systems\, and so was one of the early Putty users and testers\, with the result that the VMS specific stuff got a lot of feedback. :-)
Interesting story :-).
This kinda looks like the original issue was resolved by 9152021db0fe677bcc7f8460e5d5419a79462abc
Migrated from rt.perl.org#118447 (status was 'open')
Searchable as RT118447$