Re: scp to VMS (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
I understand this problem is fixed with the new ssh that comes with OpenVMS 8.4. Prior to this, scp does not work to openssh systems. On Wed, May 16, 2012 at 11:17 PM, Craig A. Berry craigbe...@mac.com wrote: On May 16, 2012, at 11:36 AM, Mark Berryman wrote: 1: Is there any easy way to get an scp2 client for Unix, so that I can scp to them? (And use editors remotely) SCP clients definitely work to VMS systems as I use them extensively. It has been awhile since I set up a TCPIP Services system (I use Multinet myself) but, if you have any error messages or log files, especially from the VMS side, I may be able to help. I'm almost positive scp only works with Multinet, not TCP/IP Services. IIRC, the HP scp server errors out with something about not talking SSH 1.0, only 2.0, but in fact it is its own fault for failing to recognize the 2.0 handshake sent by the client. If someone has a contrary example of using a modern scp client to talk to the TCP/IP Services server, I'd love to know how to make it work. Craig A. Berry mailto:craigbe...@mac.com ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser -- Thomas Pfau tfp...@gmail.com http://www.linkedin.com/in/thomaspfau http://nbpfaus.net/~pfau/
Re: scp to VMS
I have submitted a list of issues about the HP OpenSource cluster that Nicholas posted, and a few others that I noticed to the Office of OpenVMS programs e-mail address and a received a reply that they will be looking at getting these resolved. Regards, -John Personal Opinion Only
Re: mms case sensitivity build failures (was Re: HP hobbyist license)
On May 16, 2012, at 8:34 AM, Nicholas Clark wrote: 8: The Alpha machine fails the build because the target is converted to uppercase. How come no-one else has this problem? MMS says: $ mms/ident %MMS-I-IDENT, MMS V3.8 © Copyright 2007 Hewlett-Packard Development Company, L.P This is likely an MMS 3.8 bug as 3.8-2 on the Itanium doesn't have it. I can't reproduce it with 3.9. Hopefully John's nudge will get them to upgrade these tools. 9: The IA64 machine *initially* fails like this: MCR PTAC$DKA0:[NCLARK.I.perl5160-RC2]miniperl.exe -I[--.lib] -I[--.lib] -ME xtUtils::Command -e cp -- DYNALOADER.OPT [--.LIB.AUTO.DYNALOADER]DYNALOADER .OPT %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown. %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown. The problem here is that MMK can infer that it needs to generate dl_vms.c from dl_vms.xs, but MMS can't do that. I think I know why no-one else sees this - relates to Q10 as to why it's hidden.. The generated descrip.mms is wrong, and presumably has been for ages. DLSRC should be dl_vms.xs, not dl_vms.c. For example, on HP-UX: $ grep DLSRC ext/DynaLoader/Makefile DLSRC = dl_hpux.xs DynaLoader.xs: $(DLSRC) So, I think that that should change. Good catch. It should be fixable like so: --- configure.com;-02012-02-17 12:27:14 -0600 +++ configure.com 2012-05-17 12:01:16 -0500 @@ -6344,7 +6344,7 @@ $ WC devtype=' + devtype + ' $ WC direntrytype='struct dirent' $ WC dlext=' + dlext + ' $ WC dlobj=' + dlobj + ' -$ WC dlsrc='dl_vms.c' +$ WC dlsrc='dl_vms.xs' $ WC doublesize=' + doublesize + ' $ WC drand01=' + drand01 + ' $ WC dtrace=' + ' [end] but doesn't really matter as long as the make utility knows how to get dl_vms.c from dl_vms.xs. If I work round it like this: $ set default [.ext.DynaLoader] $ MMS all /MACRO=(DLSRC=dl_vms.xs) $ set default [--] and restart the make, it then fails like this: MCR PTAC$DKA0:[NCLARK.I.PERL5160-RC2]miniperl.exe -I[--.lib] -I[--.lib] -ME xtUtils::Command -e cp -- CWD.OPT [--.LIB.AUTO.CWD]CWD.OPT %MMS-F-GWKNOACTS, Actions to update CWD.C are unknown. %MMS-F-GWKNOACTS, Actions to update CWD.C are unknown. Unsuccessful make(dist/Cwd): code=1024 at make_ext.pl line 466. Different mms: $ mms/ident %MMS-I-IDENT, MMS V3.8-2 © Copyright 2007 Hewlett-Packard Development Company, L .P. 10: How come I'm seeing errors due to case sensitive treatment of .xs.c suffix rules? How come no-one else hits this? I don't think it's a case sensitivity problem here. MMS simply cannot handle *implicit* .xs.c rules. MMS used to work because those rules were explicit in MakeMaker. In one of the great refactorings some years ago, Schwern made the rules implicit, which broke MMS builds. I complained, but he regarded it as an MMS bug and wasn't willing to work around it. He's probably right about its being an MMS bug. I've long intended to have another crack at working around it, but obviously haven't gotten it done yet. I'm going to punt on the MMS issues for the moment. The short answer is you cannot build Perl with MMS currently but must use MMK, available here: http://www.kednos.com/kednos/Open_Source/MMK. In which case, README.vms needs some updating :-) I would rather get it working than document that it doesn't work, but yes, it would've saved you some time if the documentation reflected the reality. ___ Craig A. Berry mailto:craigbe...@mac.com ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: scp to VMS (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
On May 17, 2012, at 5:49 AM, Thomas Pfau wrote: I understand this problem is fixed with the new ssh that comes with OpenVMS 8.4. Prior to this, scp does not work to openssh systems. It seems not, actually. With a server that looks like: $ tcpip show vers HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2 on an HP rx2600 (1.50GHz/6.0MB) running OpenVMS V8.4 coming from an OS X client (with remote address changed to protect the guilty): % scp -v test.txt craig@192.168.1.2: Executing: program /usr/bin/ssh host 192.168.1.2, user craig, command scp -v -t -- . OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011 debug1: Reading configuration data /Users/craig/.ssh/config debug1: Reading configuration data /etc/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22. debug1: Connection established. debug1: identity file /Users/craig/.ssh/id_rsa type 1 debug1: identity file /Users/craig/.ssh/id_rsa-cert type -1 debug1: identity file /Users/craig/.ssh/id_dsa type -1 debug1: identity file /Users/craig/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH OpenVMS V5.5 VMS_sftp_version 3 debug1: no match: 3.2.0 SSH OpenVMS V5.5 VMS_sftp_version 3 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host '192.168.1.2' is known and matches the DSA host key. debug1: Found key in /Users/craig/.ssh/known_hosts:13 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received Welcome to HP OpenVMS Industry Standard 64 Operating System, Version V8.4 debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /Users/craig/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 debug1: Authentication succeeded (publickey). Authenticated to 192.168.1.2 ([192.168.1.2]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending command: scp -v -t -- . scp1 compatibility mode is not supported. So while I probably had the nomenclature and version numbers confused in my previous post, there is definitely something still wrong with agreeing on a mutually acceptable version of something. It looks like it's a very old problem for servers that do not support multiple protocols: http://www.snailbook.com/faq/scp-ossh-to-ssh2.auto.html. If someone finds an open source scp2 client, please holler. Craig A. Berry mailto:craigbe...@mac.com ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: mms case sensitivity build failures (was Re: HP hobbyist license)
On May 17, 2012, at 11:15 AM, Craig A. Berry wrote: On May 16, 2012, at 8:34 AM, Nicholas Clark wrote: [some text deleted] 9: The IA64 machine *initially* fails like this: MCR PTAC$DKA0:[NCLARK.I.perl5160-RC2]miniperl.exe -I[--.lib] -I[--.lib] -ME xtUtils::Command -e cp -- DYNALOADER.OPT [--.LIB.AUTO.DYNALOADER]DYNALOADER .OPT %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown. %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown. The problem here is that MMK can infer that it needs to generate dl_vms.c from dl_vms.xs, but MMS can't do that. Makefile.pl is currently placing the following lines in the MMS file: .SUFFIXES : .SUFFIXES : $(OBJ_EXT) .c .cpp .cxx .xs and .xs.c : $(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) and (for this particular instance) dl_win32.c dl_aix.c dl_dld.c dl_vmesa.c dl_dllload.c dl_dyld.c dl_none.c dl_hpux.c dl_beos.c dl_mpeix.c dl_dlopen.c dl_next.c dl_symbian.c dl_vms.c : $(XSUBPPDEPS) MMK then searches the list of suffixes that follow .c to see if it has a rule to build the .c file since no explicit action is given. It finds the .xs.c rule and executes it. MMS does not do this. There are two ways to address this. 1. Instead of having makefile.pl write out the .xs.c line as a user-defined rule, write it out as an action line after the 3rd entry above so that it reads like this: dl_win32.c dl_aix.c dl_dld.c dl_vmesa.c dl_dllload.c dl_dyld.c dl_none.c dl_hpux.c dl_beos.c dl_mpeix.c dl_dlopen.c dl_next.c dl_symbian.c dl_vms.c : $(XSUBPPDEPS) $(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) 2. When makefile.pl writes out the .xs.c user-defined rule, have it add the following: .DEFAULT : IF F$LOCATE(]XSUBPP,$+) .NE. F$LENGTH($+) THEN $(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) The second option has the added benefit of providing a null action for anything else that MMS can't figure out how to build which takes care of the actions to build STATIC not found error as well. On an unrelated issue: Can the code invoked by makefile.pl tell whether perl itself is being built or if a perl extension is being built? If so, would it be possible to have the install part of the perl build process add the following files with their indicated contents to the directory PERL_ROOT:[LIB…CORE]? __DECC_INCLUDE_EPILOGUE.H #pragma names restore __DECC_INCLUDE_PROLOGUE.H;1 #pragma names save #pragma names uppercase #pragma names truncated This way, the makefile.pl for extensions can automatically add /names=(as_is,shortened) to the CC command line when building extensions. This is a requirement to build a number of extensions, not only because they might use an external library with very long names but also because some programmers out there still think it is clever to use different routine/variable names that differ only in case. Those two files will cause all files included in, or by, the […core]*.h files to be treated as if /names=(uppercase,truncated) had been specified. The routine that converts .xs to .c already handles truncating any names that are part of perl so the shortened only takes effect for references to external libraries. Alternatively, one could build perl with /names=shortened, and change the prologue file accordingly, and completely eliminate the process of manually shortening names. Thoughts? Mark Berryman
names case-preserved and shortened (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
On May 17, 2012, at 2:47 PM, Mark Berryman wrote: Can the code invoked by makefile.pl tell whether perl itself is being built or if a perl extension is being built? If so, would it be possible to have the install part of the perl build process add the following files with their indicated contents to the directory PERL_ROOT:[LIB…CORE]? __DECC_INCLUDE_EPILOGUE.H #pragma names restore __DECC_INCLUDE_PROLOGUE.H;1 #pragma names save #pragma names uppercase #pragma names truncated This way, the makefile.pl for extensions can automatically add /names=(as_is,shortened) to the CC command line when building extensions. This is a requirement to build a number of extensions, not only because they might use an external library with very long names but also because some programmers out there still think it is clever to use different routine/variable names that differ only in case. Those two files will cause all files included in, or by, the […core]*.h files to be treated as if /names=(uppercase,truncated) had been specified. The routine that converts .xs to .c already handles truncating any names that are part of perl so the shortened only takes effect for references to external libraries. Alternatively, one could build perl with /names=shortened, and change the prologue file accordingly, and completely eliminate the process of manually shortening names. Thoughts? Starting with Perl 5.14.0, we use the compiler's name shortening by default: http://perl5.git.perl.org/perl.git/commit/1171624bdbd2f8fae38ebe18d7a2616c4435098c?f=configure.com and the compiler options you build Perl with should automatically be used for extension building. While it's a slight digression from extension building, I'll go ahead and mention that we solve the problem of predicting shortened symbol names for the linker options file used to create perlshr.exe by implementing the exact same algorithm the compiler uses to shorten symbols: http://perl5.git.perl.org/perl.git/commitdiff/24ad4a07e88519ae8e63d0b67d519e62a935b577 So that leaves building extensions using /NAMES=AS_IS. If I understand your trick with the prologue, it makes symbols declared in Perl's own headers get upper cased (and thus compatible with the default configuration of the core) while leaving any other symbols to get what you've given them on the command line. That's clever, but sounds fragile to me in that various changes to MakeMaker or ExtUtils:CBuilder or the core build process could break it, plus it would have to be done differently based on different configuration options. ISTR that building Perl with -Dusecasesensitive ran into some problem with object libraries. I would rather take another crack at resolving that and have that be the supported way to get case sensitive symbols. Craig A. Berry mailto:craigbe...@mac.com ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
