Archive-Date: Thu, 08 Feb 1996 16:53:37 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 8 Feb 1996 7:40:53 -0800 (PST) From: RICK FLOWER Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <960208074053.229e@sdvax2.sp.TRW.COM> Subject: Memory Exhausted (revisited) -- this time in GNUS.. Well, I decided the other day to fire up NNkiboze to dig up some information on Cummins diesel engines in all of the "alt" newgroups.. Anyway, I find that it will get part way searching the "titles" for the word "dodge" or "cummins" and then I get a memory exhausted message and Emacs dies (I'm running it in a batch job.. I've also tried it interactively with the same result.. The command that I'm using to invoke Emacs is below.. Also note that I'm having Emacs read my .emacs file, since it has specific pathnames in it in which to find the GNUS code.. I may try to change that by putting my altered path into my site-init.el file and removing the need for loading the .emacs file and see if that makes any difference.. emacs -batch -l sys$login:.emacs -l nnkiboze -f nnkiboze-generate-groups Any ideas? Is there anything I can do to see if Emacs is REALLY out of memory?? When it crashed yesterday, I tried the moving the cursor keys around to see if I could convince it to do a garbage collection, but I was unable to.. -- Rick ================================================================================ Archive-Date: Mon, 12 Feb 1996 16:46:55 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Mon, 12 Feb 1996 10:27:13 -0500 (EST) From: "Tim Waters - CADC Programmer (919) 541-5958" Reply-To: vms-emacs-testers@e.kth.se Subject: ISPELL To: vms-emacs-testers@e.kth.se Message-ID: <01I14F9LY0DE8ZE652@RTI.ORG> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I've just downloaded Roland's port of Ispell to VMS. However it looks like it needs the logical name emacs_library to install properly. Has anyone gotten Ispell to work with emacs 19 on VMS?? tia -- ***************************************************** * Tim Waters - CADC Programmer Analyst * * Research Triangle Institute - http://www.rti.org/ * * Phone: 919-541-5958 * * email: tgw@rti.org * ***************************************************** ================================================================================ Archive-Date: Mon, 12 Feb 1996 17:17:46 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Mon, 12 Feb 1996 17:04:47 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DCF4.AD67F618.1@e.kth.se> Subject: Re: ISPELL >From: "Tim Waters - CADC Programmer (919) 541-5958" >I've just downloaded Roland's port of Ispell to VMS. However it looks Interesting. I'd like to know where you got it, so I can mirror it. >like it needs the logical name emacs_library to install properly. Has >anyone gotten Ispell to work with emacs 19 on VMS?? Have never used it, so nope, not work has been done. But I will as soon as you give me the info I want. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Tue, 13 Feb 1996 03:52:45 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Mon, 12 Feb 1996 21:43:46 -0500 (EST) Message-ID: <199602130243.VAA20523@galileo> From: roberts@panix.com To: vms-emacs-testers@e.kth.se Subject: Re: ISPELL Reply-To: vms-emacs-testers@e.kth.se Just so you know, that patch was designed to work with Emacs 18.59 which is why it is looking for emacs_library. But the truth is, I can't remember why I would have hardcoded that. Since I no longer have access to a VMS system, I can't try to fix it myself :-( Of course, if someone wanted to donate a system.... :-) You might want to double check that the patched version wasn't from GNU ispell 4.x which is older than the current ispell 3.something (yes, really). >>>>> "Richard" == Richard Levitte <- GNU on VMS hacker > writes: >> From: "Tim Waters - CADC Programmer (919) 541-5958" >> I've just downloaded Roland's port of Ispell to VMS. However it >> looks Richard> Interesting. I'd like to know where you got it, so I can Richard> mirror it. >> like it needs the logical name emacs_library to install properly. >> Has anyone gotten Ispell to work with emacs 19 on VMS?? Richard> Have never used it, so nope, not work has been done. But I Richard> will as soon as you give me the info I want. roland -- Roland B Roberts roberts@panix.com ================================================================================ Archive-Date: Tue, 13 Feb 1996 09:19:15 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Tue, 13 Feb 1996 09:09:19 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DD7B.6BDC4C63.58@e.kth.se> Subject: Hmm, problem with PIDs Yesterday, I got bitten by the fact that PIDs are not of the form xxxxyyyy, where the xxxx part would be static on the node. I had Emacs having the PID 2020yyyy, while a subprocess had the PID 2021yyyy. Since Emacs only saves the lower 16 bits of the PID, and assumes that all subprocesses have the same upper 16 bits as it has itself, it was incapable of killing that subprocess. I've added a fix that assumes that the upper 8 bits of the PID will never change on one node. At the very least, I find it less likelly to happen. The reason I didn't fix Emacs so it saved the whole PID is that Emacs integers are 24 bits. Of course, Emacs could be changed to save the PID in two halves, but in that case, the change would be rather big, and I can't guarantee that it will be done well enough, and I can especially not guarantee that the change will work with the next version of Emacs, since PIDs are used all over the place in some modules. Does it sound likelly to you that the 8 upper bits of a PID will remain static on one node? Please advise me. Anyway, the change mentioned above will be included in the next update. Also, I would like to know from those who had problems with dired hanging, could that problem be related to this PID problem? I personally doubt it, but you never know. It could be easelly tested with a window system, or with two terminals. What I do to check such things is simply a SHOW USER/FULL from another window/terminal. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Wed, 14 Feb 1996 22:45:08 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Wed, 14 Feb 1996 13:37:31 -0800 (PST) From: RICK FLOWER Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <960214133731.2652@sdvax2.sp.TRW.COM> Subject: CALLPROC Problem??? Hi all.. I picked off the recent version of Emacs from Richard's FTP site (the one with all patches up through 11/21/95).. Anyway, it seems that whenever I tried to spawn a subprocess, I would get an error before it did the spawn.. Anyway, after poking around a bit, I found that the offending change was in [.SRC]CALLPROC.C.. I backed out the change by going to version 1 of the file and recompiled and everything was OK again.. Anyway, when I use the new version of this file, I get "Invalid Argument" errors from VMS due to the CLI$M_AUTHPRIV addition. Is there any particular reason that this was added...? Perhaps nobody else has seen this yet, but we've got a sys-admin here that likes to keep priveledges extremely tight! -- Rick SDVAX2::[SRC] $diff callproc.c callproc.c-new ************ File EMACS_LIBRARY:[SRC]CALLPROC.C;1 79 ****** File EMACS_LIBRARY:[SRC]CALLPROC.C-NEW;1 79 #define CLI$M_AUTHPRIV 128 80 ************ ************ File EMACS_LIBRARY:[SRC]CALLPROC.C;1 516 int spawn_flags = CLI$M_NOWAIT; 517 int status; ****** File EMACS_LIBRARY:[SRC]CALLPROC.C-NEW;1 517 int spawn_flags = CLI$M_NOWAIT | CLI$M_AUTHPRIV; 518 int status; ************ Number of difference sections found: 2 Number of difference records found: 2 DIFFERENCES /IGNORE=()/MERGED=1- EMACS_LIBRARY:[SRC]CALLPROC.C;1- EMACS_LIBRARY:[SRC]CALLPROC.C-NEW;1 ================================================================================ Archive-Date: Thu, 15 Feb 1996 07:38:50 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 07:31:49 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DF00.21F8E142.9@e.kth.se> Subject: Re: CALLPROC Problem??? >From: RICK FLOWER >of the file and recompiled and everything was OK again.. Anyway, when I use >the new version of this file, I get "Invalid Argument" errors from VMS due >to the CLI$M_AUTHPRIV addition. That was interesting... What VMS version are you running. Can anyone tell me in which VMS version CLI$M_AUTHPRIV was added? > Is there any particular reason that this was added...? There is a reason. I was very much annoyed when I noticed that when I started Emacs from my account with all privs set, and did a M-x shell, I had no possibility at all to use any priviledges than the default ones. I thought that adding CLI$M_AUTHPRIV would solve my problems: 7 AUTHPRIV If this bit is set, the subprocess inherits the caller's authorized privileges. If this bit is clear, the spawned pro- cesses' authorized mask is set equal to the caller's current (active) privilege mask. > Perhaps nobody else has seen this yet, but we've got a sys-admin >here that likes to keep priveledges extremely tight! I don't think he has anything to worry about. If he gave you privs, I think he should be able to trust your use of them in a subprocess. Please, dear friends, tell me if I did right or wrong. Should I remove this flag (I obviously must make it dependent on the VMS version)? Could you state a reason? Your opinion is of value here. Thanks for the report. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 15 Feb 1996 17:40:56 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 17:18:21 +0100 Message-ID: <9602151618.AA01182@dxmint.cern.ch> From: purschke@axgsi5.cern.ch (Martin Purschke, GSI, CERN-PPE) Reply-To: vms-emacs-testers@e.kth.se Subject: emacs problem on OpenVMS 6.2 Hi people, I have been running emacs 19.28 fine for some time on OpenVMS 6.1 on both Alpha and Vaxes. I now got a new Alphstation 200 4/233 with OpenVMS 6.2, and my emacs crashes with the message __sbrk(0) gave me 4E8000, which is in the middle of the code! %SYSTEM-F-DEBUG, command interpreter debugger signal at PC=000B9444, PS=0000001B Improperly handled condition, image exit forced. Signal arguments: Number = 00000003 Name = 0000046C 000B9444 0000001B Register dump: R0 = 0000000000000001 R1 = 000000000001DEF8 R2 = 000000000001CA10 .... I used first the image generated on the 6.1 system, then made a new image on the 6.2 system (which appears to be identical), same result. Any ideas anybody? Martin -- Martin Purschke ; Martin.Purschke@cern.ch ; http://www.cern.ch/WA98/PEOPLE/MLP.html CERN/PPE ; phone: +41-22-767-5920 CH-1211 Geneva 23 ; Fax: +41-22-782-4897 ------------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 15 Feb 1996 17:57:08 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 17:36:52 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DF54.A816E610.20@e.kth.se> Subject: Re: emacs problem on OpenVMS 6.2 >I have been running emacs 19.28 fine for some time on OpenVMS 6.1 >on both Alpha and Vaxes. I now got a new Alphstation 200 4/233 >with OpenVMS 6.2, and my emacs crashes with the message > > __sbrk(0) gave me 4E8000, which is in the middle of the code! Do you have the latest update (19951125)? -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 15 Feb 1996 18:13:46 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 9:02:36 -0800 (PST) From: RICK FLOWER Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <960215090236.310e@sdvax2.sp.TRW.COM> Subject: Re: CALLPROC Problem??? >>>>> "vms-emacs-testers@e" == vms-emacs-testers@e kth se writes: >> of the file and recompiled and everything was OK again.. Anyway, when I use >> the new version of this file, I get "Invalid Argument" errors from VMS due >> to the CLI$M_AUTHPRIV addition. > That was interesting... What VMS version are you running. Can anyone tell > me in which VMS version CLI$M_AUTHPRIV was added? We're running VAX/VMS 5.5-2... -- Rick ================================================================================ Archive-Date: Thu, 15 Feb 1996 20:10:41 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 19:59:28 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DF68.93C536BA.32@e.kth.se> Subject: Re: CALLPROC Problem??? >From: RICK FLOWER >>> of the file and recompiled and everything was OK again.. Anyway, when I use >>> the new version of this file, I get "Invalid Argument" errors from VMS due >>> to the CLI$M_AUTHPRIV addition. > >> That was interesting... What VMS version are you running. Can anyone tell >> me in which VMS version CLI$M_AUTHPRIV was added? > >We're running VAX/VMS 5.5-2... OK. I guess it was introduced in VMS 6.0... I'll do some extra code so it will try with AUTHPRIV first, then without... -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 15 Feb 1996 21:21:50 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 96 10:43:01 EST Message-ID: <0099DF1AD7A21DC0.006004DE@giant.IntraNet.com> From: "G. Del Merritt" Reply-To: vms-emacs-testers@e.kth.se Subject: Re: CALLPROC Problem??? To: vms-emacs-testers@e.kth.se In-reply-to: "FLOWER@sdvax2.sp.TRW.COM"'s message of 14-FEB-1996 16:57:58.24 >Hi all.. I picked off the recent version of Emacs from Richard's FTP >site (the one with all patches up through 11/21/95).. Anyway, it seems >that whenever I tried to spawn a subprocess, I would get an error before it >did the spawn.. Anyway, after poking around a bit, I found that the offending >change was in [.SRC]CALLPROC.C.. I backed out the change by going to version 1 >of the file and recompiled and everything was OK again.. Anyway, when I use >the new version of this file, I get "Invalid Argument" errors from VMS due >to the CLI$M_AUTHPRIV addition. Is there any particular reason that this was >added...? Perhaps nobody else has seen this yet, but we've got a sys-admin >here that likes to keep priveledges extremely tight! This was added as part of OpenVMS 6.0, along with the TRUSTED and SUBSYSTEM bits. If you are running 5.x (you didn't include that VMS version data), then LIB$SPAWN will return an error (sigh). This should either be #ifdef'd or you should just remember to restore the code when/if you upgrade your VMS version. These bits are described in the OpenVMS release notes and in the 6.x HELP: $ help rtl lib lib$spawn : flags OpenVMS usage mask_longword type longword (unsigned) access read only mechanism by reference Flag bits that designate optional behavior. The flags argument is the address of an unsigned longword that contains these flag bits. By default, all flags are clear. These flags are defined as follows: Bit Symbol Meaning 0 NOWAIT If this bit is set, the calling process continues executing in parallel with the subprocess. If this bit is clear, the calling process hibernates until the subprocess completes. 1 NOCLISYM If this bit is set, the spawned subprocess does not inherit CLI symbols from its caller. If this bit is clear, the subprocess inherits all currently defined CLI symbols. You may want to specify NOCLISYM to help prevent commands redefined by symbol assignments from affecting the spawned commands. 2 NOLOGNAM If this bit is set, the spawned subprocess does not inherit process logical names from its caller. If this bit is clear, the subprocess inherits all currently defined process logical names. You may want to specify NOLOGNAM to help prevent commands redefined by logical name assignments from affecting the spawned commands. 3 NOKEYPAD If this bit is set, the keypad symbols and state are not passed to the subprocess. If this bit is not set, the keypad settings are passed to the subprocess. 4 NOTIFY If this bit is set, a message is broadcast to SYS$OUTPUT when the subprocess completes or aborts. If this bit is not set, no message is broadcast. This bit should not be set unless the NOWAIT bit is also set. 5 NOCONTROL If this bit is set, no carriage-return/line-feed is prefixed to any prompt string. If this bit is not set, a carriage-return/line-feed is prefixed to any prompt string specified. 6 TRUSTED If this bit is set, it indicates a SPAWN command on behalf of the application. If this bit is not set, it indicates that the SPAWN command originates from user. SPAWN commands originating from users are disallowed in captive accounts (DCL). 7 AUTHPRIV If this bit is set, the subprocess inherits the caller's authorized privileges. If this bit is clear, the spawned processes' authorized mask is set equal to the caller's current (active) privilege mask. 8 SUBSYSTEM If this bit is set, a spawned process inherits protected subsystem IDs for the duration of LOGINOUT.EXE (used to map the CLI). The IDs will be removed in the process of transferring control to the CLI (as a user mode $RUNDWN is performed). If this bit is clear, LOGINOUT does not execute under the subsystem IDs. Bits 9 through 31 are reserved for future expansion and must be zero. Symbolic flag names are defined in Digital supplied libraries, in module $CLIDEF. They are CLI$M_NOWAIT, CLI$M_ NOCLISYM, CLI$M_NOLOGNAM, CLI$M_NOKEYPAD, CLI$M_NOTIFY, CLI$M_ NOCONTROL, CLI$M_TRUSTED, CLI$M_AUTHPRIV, and CLI$M_SUBSYSTEM. -- Del Merritt del@IntraNet.com IntraNet, Inc., One Gateway Center #700, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-6779 Just say no to Clipper. You may not add me to a commercial mailing list or send me commercial advertising without my consent. (but if you want to buy my house or car, email me for details) ================================================================================ Archive-Date: Thu, 15 Feb 1996 21:36:23 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 21:26:19 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DF74.B5EE692F.20@e.kth.se> Subject: Re: CALLPROC Problem??? >From: "G. Del Merritt" >In-reply-to: "FLOWER@sdvax2.sp.TRW.COM"'s message of 14-FEB-1996 16:57:58.24 >>Hi all.. I picked off the recent version of Emacs from Richard's FTP >>site (the one with all patches up through 11/21/95).. Anyway, it seems ... I've done the following change in VMSPROC.C and CALLPROC.C: - change: int spawn_flags = CLI$M_NOWAIT | CLI$M_AUTHPRIV; to int spawn_flags = CLI$M_NOWAIT; - change the call to lib$spawn to something like this: do { spawn_flags = spawn_flags ^ CLI$M_AUTHPRIV; status = lib$spawn (...); } while (status == LIB$_INVARG && (spawn_flags & CLI$M_AUTHPRIV)); -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 15 Feb 1996 21:50:51 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 15 Feb 1996 21:28:04 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DF74.F439538E.42@e.kth.se> Subject: Re: CALLPROC Problem??? >I've done the following change in VMSPROC.C and CALLPROC.C: Forgot to say: please test that patch, both if you run VMS 5 and if you run VMS 6. I want to make sure it is correct. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Fri, 16 Feb 1996 19:41:49 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Fri, 16 Feb 1996 13:02:10 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DFF7.729CC4AD.27@e.kth.se> Subject: Re: Compilation problem >Maybe I don't have the complete package because when >I ran @compile it refuses to create the descrip.mms and >all the other files needed to compile. Well, if you read the docs, you'd know it's not compile.com that should be run to do what you want. The correct way is to run configure.com. Doc hints: INSTALL.VMS, [.VMS]CONFIGURE.VMS_DOC (the later may be slightly outdated...). Even the REDME file is kind enough to point at INSTALL.VMS! -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Fri, 16 Feb 1996 19:41:54 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Fri, 16 Feb 1996 09:34:30 EST From: colombet@ALPHAB.CNRS-MRS.FR Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099DFDA.6F6678DA.13000@ALPHAB.CNRS-MRS.FR> Subject: Compilation problem Hi everybody, I tried to compile the emacs package on my Alpha Server which is running OpenVMS 6.1 Maybe I don't have the complete package because when I ran @compile it refuses to create the descrip.mms and all the other files needed to compile. let me show you : @compile DAB3:[COLOMBET.EMACS]CONFIGURE.COM: Neither the current directory nor its parent seem to contain the Emacs sources. If you do not want to build Emacs in its source tree, you should run `DAB3:[COLOMBET.EMACS]CONFIGURE.COM' in the directory in which you wish to build Emacs, using its `--SRCDIR' option to say where the sources may be found. Usage: DAB3:[COLOMBET.EMACS]CONFIGURE.COM CONFIGURATION [-OPTION[=VALUE] ...] Set compilation and installation parameters for GNU Emacs, and report. CONFIGURATION specifies the machine and operating system to build for. If you omit the CONFIGURATION, DAB3:[COLOMBET.EMACS]CONFIGURE.COM will find out by itself. --WITH-X Support the X Window System. --WITH-X=NO Don't support X. --WITH-GCC Use GCC to compile Emacs. --WITH-GCC=NO Don't use GCC to compile Emacs. --WITH-UCX Use the Digital UCX TCP/IP kit. --WITH-MULTINET Use the MultiNet TCP/IP kit. --WITH-DEBUG-HACK Use the dirty debug hack. See [.SRC]DESCRIP.MMS_IN_IN --RUN-IN-PLACE Use libraries and data files directly out of the source tree. --SINGLE-TREE=dev:[dir] Has the effect of creating a directory tree at dev:[dir...] which looks like: dev:[dir.BIN.configname] (emacs, etags, etc.) dev:[dir.BIN.configname.ETC] (movemail, etc.) dev:[dir.COMMON.LISP] (emacs' lisp files) dev:[dir.COMMON.SITE-LISP] (local lisp files) dev:[dir.COMMON.LIB] (DOC, TUTORIAL, etc.) dev:[dir.COMMON.LOCK] (lockfiles) --SRCDIR=dir Look for the Emacs source files in DIR. --PREFIX=dir Install files below DIR. Defaults to `SYS$SYSDEVICE:[GNU]'. --FORCE Forces a reconfiguration. You may also specify any of the `path' variables found in Makefile.in, including --bindir, --libdir, --etcdir, --infodir, and so on. This allows you to override a single default location when configuring. If successful, 'progname' leaves its status in config.status. If unsuccessful after disturbing the status quo, it removes config.status." %NONAME-W-NOMSG, Message number 00000000 I tried to build the package in a different tree but the results were the same. I hope someone could help me. Cheers Bruno. Bruno COLOMBET OBSERVATOIRE DE MARSEILLE FRANCE colombet@obmara.cnrs-mrs.fr ================================================================================ Archive-Date: Mon, 19 Feb 1996 09:35:07 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Mon, 19 Feb 1996 09:23:46 EST From: colombet@ALPHAB.CNRS-MRS.FR Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E234.6F212AFD.13052@ALPHAB.CNRS-MRS.FR> Subject: Re: Compilation problem >Maybe I don't have the complete package because when >I ran @compile it refuses to create the descrip.mms and >all the other files needed to compile. Richard Levitte said : >Well, if you read the docs, you'd know it's not >compile.com that should >be run to do what you want. The correct way is to run >configure.com. Yes, of course, your're right, I made a mistake when I wrote @compile, I wanted to say @configure. and I read the docs, and the example given : @configure vax-dec-vms5.4 --with-x11 Nothing happened, and I have the same answers as I said in a previous mail. So let's continue on the same way. Bruno. ================================================================================ Archive-Date: Mon, 19 Feb 1996 16:54:40 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Mon, 19 Feb 1996 16:43:40 +0100 Message-ID: <9602191543.AA24825@dxmint.cern.ch> From: purschke@axgsi5.cern.ch (Martin Purschke, GSI, CERN-PPE) Reply-To: vms-emacs-testers@e.kth.se Subject: Re: emacs problem on OpenVMS 6.2 >>I have been running emacs 19.28 fine for some time on OpenVMS 6.1 >>on both Alpha and Vaxes. I now got a new Alphstation 200 4/233 >>with OpenVMS 6.2, and my emacs crashes with the message >> >> __sbrk(0) gave me 4E8000, which is in the middle of the code! > >Do you have the latest update (19951125)? > Well I have the updates through 19951121 - I did not find 19951125. Did I miss it, or is the 25 a typo? Martin ================================================================================ Archive-Date: Mon, 19 Feb 1996 23:52:52 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Mon, 19 Feb 1996 23:46:02 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E2AC.E4062EBD.42@e.kth.se> Subject: Re: emacs problem on OpenVMS 6.2 >From: purschke@axgsi5.cern.ch (Martin Purschke, GSI, CERN-PPE) >>>I have been running emacs 19.28 fine for some time on OpenVMS 6.1 >>>on both Alpha and Vaxes. I now got a new Alphstation 200 4/233 >>>with OpenVMS 6.2, and my emacs crashes with the message >>> >>> __sbrk(0) gave me 4E8000, which is in the middle of the code! >> >>Do you have the latest update (19951125)? >> > > Well I have the updates through 19951121 - I did not >find 19951125. Did I miss it, or is the 25 a typo? It is a typo. Sorry. It was a very long time since I last saw the error presented above. Did you say that you did rebuild it for VMS 6.2? I quite clearly remember having to do exactly that, for reasons unknown to me. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Tue, 20 Feb 1996 11:31:58 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Tue, 20 Feb 1996 11:14:48 +0100 Message-ID: <9602201014.AA11232@dxmint.cern.ch> From: purschke@axgsi5.cern.ch (Martin Purschke, GSI, CERN-PPE) Reply-To: vms-emacs-testers@e.kth.se Subject: Re: emacs problem on OpenVMS 6.2 >>> __sbrk(0) gave me 4E8000, which is in the middle of the code! >> ... >It was a very long time since I last saw the error presented above. Did >you say that you did rebuild it for VMS 6.2? I quite clearly remember >having to do exactly that, for reasons unknown to me. Well I did rebuild the image on the 6.2 system. I doesn't help. The only difference is that this version doesn't give the ominous __sbrk(0) gave me 4E8000, which is in the middle of the code! message, but only the Improperly handled condition, image exit forced. Signal arguments: Number = 00000003 Name = 0000046C 000A2974 0000001B message. The 6.2-generated image appears to run fine on the 6.1 system, but I did not test it extensively. Also, depending on the file I edit, the crash comes sooner or later. I have a file which reproduces the crash. Cheers, Martin ================================================================================ Archive-Date: Fri, 23 Feb 1996 17:43:56 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Fri, 23 Feb 1996 8:35:40 -0800 (PST) From: RICK FLOWER Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <960223083540.52c3@sdvax2.sp.TRW.COM> Subject: SMTP.EL -- I'm working on it again... Ok.. I'm doing a bit of work on my SMTP.EL package that I started a while back as many of you recall.. I've not done anything with it for quite a while and wanted to get some of the features that everyone was looking for installed into the code.. The main thing that I'm trying to figure out how to handle is when the user wishes to send an e-mail to mixed address types such as some internet destinations and some DECnet destinations.. I suppose that the best way would be to create two separate messages : 1) DECnet destined address (pass this via VMSSENDMAIL.EXE) 2) Internet destined address (allow SMTP.EL to talk w/ SMTP server if enabled to do so) I suspect that if I were to do it this way, then the destination site would not be able to see all of the destinations that this message was going to. (ie. If a message was being sent to REMOTEVAX::SMITH and CC'd to flower@emu, then REMOTEVAX::SMITH wouldn't know that it was also CC'd to flower@emu and vice-versa) I'm going to allow the user (via the global variable vms-use-smtp-server) to disable communication with an SMTP server -- in fact, perhaps I should make it disabled by default (probably a better assumption). If talking with an SMTP server is disabled, then all mail will be fed into VMSSENDMAIL.EXE Anyway, if there is anything that I'm forgetting here, please let me know. And yes, there are already variables for setting with SMTP port number to use, etc.. -- Rick ================================================================================ Archive-Date: Fri, 23 Feb 1996 18:49:19 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Fri, 23 Feb 96 09:41:28 PST From: pf%rm763b@Riem.Com Reply-To: vms-emacs-testers@e.kth.se Message-ID: <960223094128.c23@Riem.Com> Subject: DECC 5.2 To: vms-emacs-testers@e.kth.se DECC on our cluster was just upgraded to 5.2. We're often running field test, but this is a release: 5.2-003. On AXP 6.2. I'd had this problem with dired hanging. Sent out a bunch of messages on this maybe a month or 2 ago, but it was never fixed. One speculation from Richard was that it might be compiler-related. So I figured I'd try out the new compiler. Configure with: > @configure.com --PREFIX=DISK$prod_A:[GNU] --WITH-X --EXEC_PREFIX=DISK$prod_A:[GNU.AXP] --WITH-TCPIP=NO Have to turn TCPIP off for complicated reasons relating to our installation. So this worked. Then mms/ignor=warn install . . . CC /define=("__foo__" 'extra_defs') /include=(sys$disk:[],DISK$USER_A:[PF.EMACS.EMACS-19_28.VMS]'extra_incl') /NESTED=INCLUDE 'extr a_cflags' DISK$USER_A:[PF.EMACS.EMACS-19_28.VMS]UTIME.C /obj = sys$disk:[]UTIME.obj - !/list=sys$disk:[]UTIME.lis/show=all library/replace/object VMSLIB.OLB UTIME.OBJ CC /define=("__foo__" 'extra_defs') /include=(sys$disk:[],DISK$USER_A:[PF.EMACS.EMACS-19_28.VMS]'extra_incl') /NESTED=INCLUDE 'extr a_cflags' DISK$USER_A:[PF.EMACS.EMACS-19_28.VMS]HACKDEBUG.C /obj = sys$disk:[]HACKDEBUG.obj - !/list=sys$disk:[]HACKDEBUG.lis/show=all ssize_t read (int __file_desc, void *__buffer, size_t __nbytes); ............^ %CC-E-NOTCOMPAT, In this declaration, the type of "decc$read" is not compatible with the type of a previous declaration of "decc$rea d" at line number 644 in file AXP_COMMON:[SYSLIB]DECC$RTLDEF.TLB;5. at line number 201 in module UNIXIO of text library AXP_COMMON:[SYSLIB]DECC$RTLDEF.TLB;5 %MMS-F-ABORT, For target HACKDEBUG.OBJ, CLI returned abort status: %X10B91262. %MMS-F-ABORT, For target [.VMS], CLI returned abort status: %X10EE8034. Hmm decc$read declared twice. The first time in decc$rtldef.tlb which is presumeably new with the new compiler. Maybe I can just remove the reference from hackdebug (or one of its headers as the case may be)? pat ================================================================================ Archive-Date: Fri, 23 Feb 1996 19:13:47 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Fri, 23 Feb 96 10:08:00 PST From: pf%rm763b@Riem.Com Reply-To: vms-emacs-testers@e.kth.se Message-ID: <960223100800.c30@Riem.Com> Subject: DECC 5.2 part II To: vms-emacs-testers@e.kth.se Ok "solved" the earlier problem by simply deleting the following section from hackdebug.c: #ifdef __DECC #define close decc$close #define lseek decc$lseek #define open decc$open #define read decc$read #define write decc$write #endif I have no idea if this is the correct thing to do. But it seemed reasonable and hackdebug.c _did_ then compile. mms chunks along further. Until we get to: ! on error then sh process/quota CC /define=("emacs",HAVE_CONFIG_H 'extra_defs')/include=(local_includes:) /nooptimize /standard=vaxc /WARNING=(DISABLE=(ADDRCONS TEXT,GLOBALEXT,LONGEXTERN)) /prefix=all /NESTED=INCLUDE /debug DISK$USER_A:[PF.EMACS.EMACS-19_28.SRC]VMSPROC.C /obj - = sys$disk:[]VMSPROC.obj !/list=sys$disk:[]VMSPROC.lis/show=all int *rdsc; .........^ %CC-E-PROMOTMATCH, In the definition of the function "sys_select", the promoted type of rdsc is incompatible with the type of the co rresponding parameter in a prior declaration. at line number 308 in file DISK$USER_A:[PF.EMACS.EMACS-19_28.SRC]VMSPROC.C;3 int *wdsc; .........^ %CC-E-PROMOTMATCH, In the definition of the function "sys_select", the promoted type of wdsc is incompatible with the type of the co rresponding parameter in a prior declaration. at line number 309 in file DISK$USER_A:[PF.EMACS.EMACS-19_28.SRC]VMSPROC.C;3 int *edsc; .........^ %CC-E-PROMOTMATCH, In the definition of the function "sys_select", the promoted type of edsc is incompatible with the type of the co rresponding parameter in a prior declaration. at line number 310 in file DISK$USER_A:[PF.EMACS.EMACS-19_28.SRC]VMSPROC.C;3 %MMS-F-EXEDELPROC, Subprocess terminated abnormally. %MMS-F-ABORT, For target [.SRC], CLI returned abort status: %X10EE80EC. Hmm params to sys_select. Well I see a select but not a sys_select in vmsproc.c. But the offending line numbers are rdsc, wdsc, etc where they're declared as the params to select. Just an idea. I think the code (select() in vmsproc.c) says that we're emulating a select call. Maybe select is now in the RTL and can be removed from here? pat ================================================================================ Archive-Date: Fri, 23 Feb 1996 23:26:14 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Fri, 23 Feb 1996 16:45:43 -0500 Message-ID: <96022316454281@nscl.msu.edu> From: ibbotson@nscl.msu.edu (Rich Ibbotson) Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Subject: a minor point I'm trying to install emacs on both a VAX and an AXP system from the same place, and I'm having a few minor (so far) problems as a result. It looks to me (and I know little about these things, so please correct me) like if I create routines.tpu$section under AXP, I need to re-create it under VMS for that system. Trouble is, it never gets removed with either "mms clean" or "mms distclean". Also, some things are not removed with "distclean" that are removed with "clean" (such as vmslib.olb). Is this one of those things I should just know about, or should "mms distclean" also do everything that "clean" does? Seems like it's not really distribution-clean this way. Rich Ibbotson@nscl.msu.edu ================================================================================ Archive-Date: Sun, 25 Feb 1996 17:38:29 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Sun, 25 Feb 1996 17:31:17 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E72F.8869A929.3@e.kth.se> Subject: Re: DECC 5.2 >From: pf%rm763b@Riem.Com >CC /define=("__foo__" 'extra_defs') /include=(sys$disk:[],DISK$USER_A:[PF.EMACS.EMACS-19_28.VMS]'extra_incl') /NESTED=INCLUDE 'extr >a_cflags' DISK$USER_A:[PF.EMACS.EMACS-19_28.VMS]HACKDEBUG.C /obj = sys$disk:[]HACKDEBUG.obj - >!/list=sys$disk:[]HACKDEBUG.lis/show=all > > ssize_t read (int __file_desc, void *__buffer, size_t __nbytes); >............^ >%CC-E-NOTCOMPAT, In this declaration, the type of "decc$read" is not compatible with the type of a previous declaration of "decc$rea >d" at line number 644 in file AXP_COMMON:[SYSLIB]DECC$RTLDEF.TLB;5. >at line number 201 in module UNIXIO of text library AXP_COMMON:[SYSLIB]DECC$RTLDEF.TLB;5 >%MMS-F-ABORT, For target HACKDEBUG.OBJ, CLI returned abort status: %X10B91262. >%MMS-F-ABORT, For target [.VMS], CLI returned abort status: %X10EE8034. > > Hmm decc$read declared twice. The first time in >decc$rtldef.tlb which is presumeably new with the new compiler. >Maybe I can just remove the reference from hackdebug (or one of >its headers as the case may be)? Actually, it's decc$read() that is declared once, and read() once, but since hackdebug.c contains a "#define read decc$read" (which is needed to avoid linking errors), it looks like decc$read is declared twice (and differently). I've done a quick fix for this, having to somewhat end over twice to get it right. I'm right now going through all the reports I've got since november, and will fix all reported bugs, and then produce an update and a new complete distribution. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Sun, 25 Feb 1996 17:59:08 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Sun, 25 Feb 1996 17:53:22 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E732.9E1865AD.50@e.kth.se> Subject: Re: DECC 5.2 part II >From: pf%rm763b@Riem.Com > Ok "solved" the earlier problem by simply deleting the >following section from hackdebug.c: > >#ifdef __DECC >#define close decc$close >#define lseek decc$lseek >#define open decc$open >#define read decc$read >#define write decc$write >#endif Did it link cleanly when you did so? It didn't for me (the linker complained about CLOSE, LSEEK, OPEN and WRITE missing). -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Sun, 25 Feb 1996 18:22:54 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Sun, 25 Feb 1996 18:16:01 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E735.C83817F5.13@e.kth.se> Subject: Re: a minor point >From: ibbotson@nscl.msu.edu (Rich Ibbotson) >I'm trying to install emacs on both a VAX and an AXP system from the same >place, and I'm having a few minor (so far) problems as a result. It looks >to me (and I know little about these things, so please correct me) like >if I create routines.tpu$section under AXP, I need to re-create it >under VMS for that system. Trouble is, it never gets removed >with either "mms clean" or "mms distclean". I was under the impression that TPU sections where byte-compatable between the systems... My fault... > Also, some things are not removed with "distclean" that are removed >with "clean" (such as vmslib.olb). Is this one of those things I should >just know about, or should "mms distclean" also do everything that >"clean" does? Seems like it's not really distribution-clean this way. The library wasn't removed because of a bug in the description file. DELETE.COM expects all the files to delete to be in P1 (comma-separated). Unfortunatelly, there was this line in [.VMS]DESCRIP.MMS_IN: UTILITIES = hackdebug.exe check_verb.exe and since the distclean action looks like this: clean : mostlyclean - @$(vmssrcdir)delete $(INSTALLABLES),$(UTILITIES),$(LIBRARIES) (which expands to: clean : mostlyclean - @$(vmssrcdir)delete ,hackdebug.exe check_verb.exe,vmslib.olb ) only hackdebug.exe is removed... I've corrected the error like this: UTILITIES = hackdebug.exe,check_verb.exe I've also added a little to the clean action lines: clean : mostlyclean - @$(vmssrcdir)delete $(INSTALLABLES),$(UTILITIES),$(LIBRARIES) - @$(vmssrcdir)delete routines.tpu$section -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Sun, 25 Feb 1996 18:41:28 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Sun, 25 Feb 1996 18:33:59 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E738.4AA9D361.22@e.kth.se> Subject: Re: SMTP.EL -- I'm working on it again... >From: RICK FLOWER >internet destinations and some DECnet destinations.. I suppose that the best >way would be to create two separate messages : > > 1) DECnet destined address (pass this via VMSSENDMAIL.EXE) > 2) Internet destined address (allow SMTP.EL to talk w/ SMTP server > if enabled to do so) >I suspect that if I were to do it this way, then the destination site would >not be able to see all of the destinations that this message was going to. >(ie. If a message was being sent to REMOTEVAX::SMITH and CC'd to flower@emu, >then REMOTEVAX::SMITH wouldn't know that it was also CC'd to flower@emu and >vice-versa) Actually, I'm starting to believe that the best thing would be to hack this into VMSSENDMAIL. I think it should have the capabilities to handle email like this: To: REMOTEVAX::SMITH Cc: MX%"levitte@e.kth.se" ... at least when it comes to SMTP, it's quite easy to tell the server for e.kth.se that the mail should be sent to levitte@e.kth.se, and have it swallow all the needed To: and Cc: lines. I know it's perfectly possible to talk directly to the MAIL object on REMOTEVAX. The question is if it's possible to tell it to give the mail message to SMITH, and have it swallow the Cc: header without having it send me the letter a second time. Anybody who knows more about this? Hmm... Sounds like we need to have a second implementation of VMSSENDMAIL if you choose to go that way... >I'm going to allow the user (via the global variable vms-use-smtp-server) >to disable communication with an SMTP server -- in fact, perhaps I should >make it disabled by default (probably a better assumption). If talking with >an SMTP server is disabled, then all mail will be fed into VMSSENDMAIL.EXE Wise decision. >Anyway, if there is anything that I'm forgetting here, please let me know. >And yes, there are already variables for setting with SMTP port number to use, >etc.. Where's the code? I would like to take a look at it. A thought just came to me: Emacs already talks TCP/IP, perhaps should it be made to talk DECnet as well? I'm talking networking here, not just FAL. Comments? -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Sun, 25 Feb 1996 18:50:55 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Sun, 25 Feb 1996 18:44:39 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E739.C7F4D598.13@e.kth.se> Subject: DCL mode new version as of 1996-02-12 Odd Gripenstam has enhanced his DCL mode again. Please try it out. It's available as ftp.vms.stacken.kth.se:[.GNU-VMS.BETA]DCL-MODE-19960212.EL. As I understand it, Odd thinks it's almost ready for a real release, so please test it good. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Sun, 25 Feb 1996 19:46:42 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Sun, 25 Feb 1996 19:38:23 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E741.49BAED52.42@e.kth.se> Subject: New update for Emacs 19.28 as of 1996-02-25 A new update is now available as ftp.vms.stacken.kth.se:[.GNU-VMS]EMACS-19_28-UPDATES-19960225.TAR-GZ. Please download it and try it out. I will also make a complete source distribution within the hour. The following files have been changed: Feb 25 19:26:17 1996 44195 emacs-19_28/descrip.mms_in Feb 25 19:26:17 1996 4923 emacs-19_28/lib-src/$change_log$.txt Feb 25 19:26:17 1996 14274 emacs-19_28/lib-src/descrip.mms_in_in Feb 25 19:26:18 1996 79838 emacs-19_28/lib-src/etags.c Feb 25 19:26:18 1996 22026 emacs-19_28/lib-src/getopt.c Feb 25 19:26:18 1996 8772 emacs-19_28/lib-src/qsort.c Feb 25 19:26:18 1996 629 emacs-19_28/lisp/descrip.mms Feb 25 17:42:23 1996 0 emacs-19_28/lisp/term/ Feb 25 19:26:18 1996 3162 emacs-19_28/lwlib/descrip.mms_in Feb 25 19:26:18 1996 19392 emacs-19_28/src/$change_log$.txt Feb 25 17:42:24 1996 0 emacs-19_28/src/bitmaps/ Feb 25 19:26:18 1996 34270 emacs-19_28/src/callproc.c Feb 25 19:26:18 1996 42304 emacs-19_28/src/descrip.mms_in_in Feb 25 19:26:04 1996 50977 emacs-19_28/src/gmalloc.c-try Feb 25 19:26:18 1996 103048 emacs-19_28/src/process.c Feb 25 19:26:19 1996 4184 emacs-19_28/src/process.h Feb 25 19:26:05 1996 135638 emacs-19_28/src/sysdep.c_old Feb 25 19:26:19 1996 20418 emacs-19_28/src/vmsmap.c Feb 25 19:26:19 1996 45477 emacs-19_28/src/vmsproc.c Feb 25 19:26:06 1996 3053 emacs-19_28/src/vmsproc.c_diff Feb 25 19:26:06 1996 45156 emacs-19_28/src/vmsproc.c_old Feb 25 19:26:19 1996 513 emacs-19_28/src/s/$change_log$.txt Feb 25 19:26:19 1996 12506 emacs-19_28/src/s/vms.h Feb 25 19:26:19 1996 10229 emacs-19_28/vms/$change_log$.txt Feb 25 19:26:19 1996 6315 emacs-19_28/vms/descrip.mms_in Feb 25 19:26:19 1996 2242 emacs-19_28/vms/hackdebug.c And here are the changes in the change logs: [.LIB-SRC]$CHANGE_LOG$.TXT: Sun Feb 25 17:00:08 1996 Richard Levitte * qsort.c: made sure alloca() is correctly declared. Wed Dec 27 21:31:54 1995 Richard Levitte * etags.c (relative_filename, absolute_filename, absolute_dirname): changed to work with VMS file specifications. Wed Dec 13 00:16:58 1995 Richard Levitte * etags.c (main): rebalanced a couple of braces. Sat Dec 9 18:11:47 1995 Richard Levitte * descrip.mms_in_in (dotstar): DEC C 5.x and up change `.*' to `. *'. Because of this, all `.*' are replaced with $(dotstar). [.SRC]$CHANGE_LOG$.TXT: Sun Feb 25 16:18:56 1996 Richard Levitte * callproc.c, vmsproc.c: include libdef.h to get LIB$_INVARG. Sat Jan 13 02:31:02 1996 Richard Levitte * vmsproc.c (init_vmsproc): slight reorganisation Sat Dec 9 18:13:18 1995 Richard Levitte * descrip.mms_in_in (dotstar): DEC C 5.x and up change `.*' to `. *'. Because of this, all `.*' are replaced with $(dotstar). Wed Nov 29 13:41:07 1995 Richard Levitte * vmsproc.c: undefine select and connect before include TCP/IP header files, and redefine them after. [.SRC.S]$CHANGE_LOG$.TXT Sun Feb 25 17:00:43 1996 Richard Levitte * vms.h: corrected an erroneous #if to be an #ifdef. [.VMS]$CHANGE_LOG$.TXT: Sun Feb 25 12:33:25 1996 Richard Levitte * descrip.mms_in (distclean): Added deletion of routines.tpu$section. * hackdebug.c: had to bend over to get the declaration of read() through with no compiler warnings and no linking errors. This applies to DEC C 5.2 only (or at least so far). I'm not absolutelly sure etags works as it should yet. Is there anything I have left out or forgotten? Please tell me. Is there anything that you notice as improved that I didn't notice? For example, has dired stopped hanging? Please tell me. -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Wed, 28 Feb 1996 03:57:24 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Message-ID: <2.2.32.19960228024525.006921b4@pop.j51.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 1996 21:45:25 -0500 To: vms-emacs-testers@e.kth.se From: JNC Consulting Group Reply-To: vms-emacs-testers@e.kth.se Subject: Problems building latest update I untarred the latest update and tried rebuilding. The build is crashing when trying to execute the non-existent (on my system) CHECK_VERB program. Was this introduced in a prior update release? I am current through the September release but just realized that I missed the two November releases. Will applying the November releases and then reapplying this release straighten me out? --- Jake Colman email: jcolman@jnc.com JNC Consulting Group Inc. Phone: (914) 368-2765 42 Olympia Lane FAX : (914) 368-2765 Monsey, NY 10952 ================================================================================ Archive-Date: Wed, 28 Feb 1996 22:20:15 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se From: u177k@gsde.hso.link.com Reply-To: vms-emacs-testers@e.kth.se Message-ID: <199602282051.OAA09757@oss2> Subject: Re: New update for Emacs 19.28 as of 1996-02-25 To: vms-emacs-testers@e.kth.se Date: Wed, 28 Feb 1996 14:51:28 -0600 (CST) CC: levitte@e.kth.se MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Richard, 1) Thanks for your efforts on our behalf. 2) Help! My attempts to download a copy of the 19960225 revision *master* archive have been "closed by peer" after around 10000 to 11000 blocks are transferred. (I'm only getting it because I can't make the old stuff "mmk distclean" properly, and trying to fool it with "mmk check_verb.obj" is bombing because certain lib*.h files are absent... I can provide logs. gcc=2.7.1) I retrieved the revision *update* archive with no problems. Is something timing out on ftp.vms.stacken, due to the large file size....? Workarounds? ================================================================================ Archive-Date: Wed, 28 Feb 1996 23:06:32 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se From: u177k@gsde.hso.link.com Reply-To: vms-emacs-testers@e.kth.se Message-ID: <199602282146.PAA21675@oss2> Subject: Re: New update for Emacs 19.28 as of 1996-02-25 To: vms-emacs-testers@e.kth.se Date: Wed, 28 Feb 1996 15:46:48 -0600 (CST) CC: levitte@e.kth.se MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Weellll, that figures. About 15 minutes after sending my plea for help, I was able to retrieve the entire master save-set. Sorry for the list traffic. ================================================================================ Archive-Date: Wed, 28 Feb 1996 23:51:46 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se From: u177k@gsde.hso.link.com Reply-To: vms-emacs-testers@e.kth.se Message-ID: <199602282222.QAA28034@oss2> Subject: problems with new distribution To: vms-emacs-testers@e.kth.se Date: Wed, 28 Feb 1996 16:22:53 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I can't seem to get the distribution to build on OVMS 6.2 with gcc 2.7.1 (the Pat Rankin version for VMS): I'm configuring the distribution "right out of the package", and I get some warnings, and an odd error at the end. Then I invoke "mmk /ign=warning" and get as far as hackdebug before bombing the make. Could someone suggest well-known fixes I might have missed, before I dive in to .COM file hacking? My *trimmed* logs are below: EMACS-19_28> @configure --with-ucx [lots of status indications trimmed...] Using Xlib directly. examining the machine- and system-dependent files to find out - which libraries the lib-src programs will want, and - whether the GNU malloc routines are usable %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \YES\ %SEARCH-W-OPENIN, error opening TALUME$DKA300:[EM1928.EMACS-19_28]CONFIGURE-TMP. C-I; as input -RMS-E-FNF, file not found %SEARCH-E-NOFILE, no file found %DCL-W-UNDSYM, undefined symbol - check validity and spelling \UNEXEC\ %DCL-W-UNDSYM, undefined symbol - check validity and spelling \C_SWITCH_SYSTEM\ %DCL-W-UNDSYM, undefined symbol - check validity and spelling \LIBSRC_LIBS\ checking for XrmSetDatabase checking for XScreenResourceString [lots of status indications trimmed...] checking for socket Emacs version is 19.28 Configured for `vax-dec-vms6.2'. Where should the build process find the source code? TALUME$DKA300:[EM1928. EMACS-19_28] What operating system and machine description files should Emacs use? `vms5-5.h' and `vax.h' What compiler should emacs be built with? gcc /NOCASE_HACK Should Emacs use the GNU version of malloc? NO(The GNU allocators don't work with this system configuration.) Should Emacs use the relocating allocator for buffers? NO What window system should Emacs use? x11 What toolkit should Emacs use? NONE Where do we find X Windows header files? DECW$INCLUDE: Where do we find X Windows libraries? SYS$LIBRARY: creating config.status creating descrip.mms creating [.lib-src]descrip.mms_in creating [.oldXMenu]descrip.mms creating [.lwlib]descrip.mms creating [.src]descrip.mms_in creating [.vms]descrip.mms creating [.vms]emacs_vue.com creating [.src]config.h creating [.lib-src]descrip.mms creating [.src]descrip.mms junk.c:1256: invalid preprocessing directive name .EMACS-19_28> ........and now the "make"........... .EMACS-19_28> mmk/ign=warn all = "" __result := no __command := if f$type(MMK) .eqs. "STRING" then __result := yes if __result then __command = MMK if __result then sh sym MMK MMK == "$TALUME$DKA300:[STUFF.MMK]mmk" if __result .and. f$extract(0,1,f$edit(__command,"TRIM")) .eqs. "$" then __c ommand = f$edit(__command - "$","TRIM") sh sym __command __COMMAND = "TALUME$DKA300:[STUFF.MMK]mmk" if __result then __command = f$edit(__command - "MCR ","TRIM") sh sym __command __COMMAND = "TALUME$DKA300:[STUFF.MMK]mmk" if __result then open/write foo [.vms]make-command.cld if __result then write foo "define verb MMK" if __result then write foo " image ",__command,",cliflags(foreign)" if __result then close foo if __result then set command [.vms]make-command.cld if __result then delete/symbol/global MMK if __result then delete/symbol/local MMK %DCL-W-UNDSYM, undefined symbol - check validity and spelling delete/symbol/local __result delete/symbol/local __command %MMK-I-ACTNOUPD, action did not update target FRC.SRC.PATHS.H set def [.vms] MMK /IGNORE=WARN routines.tpu$section if "" .nes. "" then define /nolog sys ,sys$disk:[] if "" .eqs. "" then define /nolog sys sys$disk:[] set def [-] Producing `[.src]paths.h' from `TALUME$DKA300:[EM1928.EMACS-19_28.src]paths.h_in '. Producing `[.vms]runtemacs.com'. Producing `[.vms]vmslink.opt'. Producing `[.vms]config.dat'. %MMK-I-ACTNOUPD, action did not update target FRC.VMS set def [.vms] MMK /IGNORE=WARN /macro=("CC=GCC","CFLAGS=/NOCASE_HACK","CPPFLAGS=", "LDFLAGS=","MAKE=MMK") all_hackargv,all_utime,hackdebug.exe,check_verb.exe if "" .nes. "" then define /nolog sys ,sys$disk:[] if "" .eqs. "" then define /nolog sys sys$disk:[] library/create/object vmslib.olb [...compiles ok...] library/replace/object VMSLIB.OLB PIPE.OBJ [...ditto...] library/replace/object VMSLIB.OLB ESCTRANS.OBJ [...ditto...] library/replace/object VMSLIB.OLB GLOB.OBJ [...ditto...] library/replace/object VMSLIB.OLB HACKARGV.OBJ [...ditto...] library/replace/object VMSLIB.OLB MISC.OBJ GCC /define=("__foo__" 'extra_defs') /include=(sys$disk:[],TALUME$DKA300:[EM1928 .EMACS-19_28.VMS]'extra_incl') /NOCASE_HACK 'extra_cflags' TALUME$DKA300:[EM192 8.EMACS-19_28.VMS]UTIME.C /obj = sys$disk:[]UTIME.obj talume$dka300:[em1928.emacs-19_28.vms]utime.c: In function `utime': talume$dka300:[em1928.emacs-19_28.vms]utime.c:190: warning: initialization makes integer from pointer without a cast talume$dka300:[em1928.emacs-19_28.vms]utime.c:191: warning: initialization makes integer from pointer without a cast talume$dka300:[em1928.emacs-19_28.vms]utime.c:192: warning: initialization makes integer from pointer without a cast talume$dka300:[em1928.emacs-19_28.vms]utime.c:193: warning: initialization makes integer from pointer without a cast talume$dka300:[em1928.emacs-19_28.vms]utime.c:194: warning: initialization makes integer from pointer without a cast talume$dka300:[em1928.emacs-19_28.vms]utime.c:195: warning: initialization makes integer from pointer without a cast library/replace/object VMSLIB.OLB UTIME.OBJ GCC /define=("__foo__" 'extra_defs') /include=(sys$disk:[],TALUME$DKA300:[EM1928 .EMACS-19_28.VMS]'extra_incl') /NOCASE_HACK 'extra_cflags' TALUME$DKA300:[EM192 8.EMACS-19_28.VMS]HACKDEBUG.C /obj = sys$disk:[]HACKDEBUG.obj talume$dka300:[em1928.emacs-19_28.vms]hackdebug.c: In function `main': talume$dka300:[em1928.emacs-19_28.vms]hackdebug.c:87: `SEEK_SET' undeclared (fir st use this function) talume$dka300:[em1928.emacs-19_28.vms]hackdebug.c:87: (Each undeclared identifie r is reported only once talume$dka300:[em1928.emacs-19_28.vms]hackdebug.c:87: for each function it appea rs in.) %GCC-E-NOOBJECT, no object file was produced %MMK-F-ERRUPD, error status %X1000002C occurred when updating target HACKDEBUG.O BJ %MMK-F-ERRUPD, error status %X1C14803C occurred when updating target [.VMS] .EMACS-19_28> ================================================================================ Archive-Date: Thu, 29 Feb 1996 02:29:29 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 29 Feb 1996 02:19:59 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E9D4.E373A7F4.14@e.kth.se> Subject: Re: New update for Emacs 19.28 as of 1996-02-25 >From: u177k@gsde.hso.link.com >Weellll, that figures. About 15 minutes after sending my plea for help, >I was able to retrieve the entire master save-set. Sorry for the list >traffic. No problem. I've had several complaints about the FTP server on ftp.vms.stacken.kth.se... -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 29 Feb 1996 02:29:32 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 29 Feb 1996 02:18:22 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <0099E9D4.A97DC344.5@e.kth.se> Subject: Re: New update for Emacs 19.28 as of 1996-02-25 >From: u177k@gsde.hso.link.com > 1) Thanks for your efforts on our behalf. :-) You're welcome. > 2) Help! >My attempts to download a copy of the 19960225 revision *master* archive >have been "closed by peer" after around 10000 to 11000 blocks are transferred. Unfortunatelly, MadGoat FTP (which is the server used) does not work well with NETLIB 2.0 (any revision). The symptom is a crash of the listener, resulting in the "closed by peer" you experience. I've made a small attempt to run MGFTP with a more or less private copy of NETLIB 1.7, unfortunatelly without success. I will do a greater effort tomorrow (thursday) evening. >(I'm only getting it because I can't make the old stuff "mmk distclean" >properly, and trying to fool it with "mmk check_verb.obj" is bombing The distclean can be more or less simulated with these commands: $! SET DEFAULT to the Emacs source tree root $ DELETE [...]*.OBJ;*,*.OLB;* $ DELETE [.SRC]PATHS.H;* $ @CONFIG.STATUS --RECHECK That's about what you need to cause a complete recompilation (I really don't think I've left anything out here). >because certain lib*.h files are absent... I can provide logs. gcc=2.7.1) >I retrieved the revision *update* archive with no problems. Is something Hmm, do you have the previous full source? In that case, unpack the update(s) you need to get to the latest revision. I have added the archive to another machine, but be prepared, it's a MicroVAX II, which means it's not terribly fast... The name is ftp.lp.se. Please only use in emergency cases (like when ftp.vms.stacken.kth.se won't give you the file(s) after several tries). -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 29 Feb 1996 10:02:09 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 29 Feb 1996 09:50:40 +0100 From: Richard Levitte - GNU on VMS hacker Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se CC: JNEWMAN@THUBAN.AC.HMC.EDU Message-ID: <0099EA13.D923CF2E.20@e.kth.se> Subject: ["Janet L. Newman" : Re: Gnu Emacs build on VMS] The following report looks like a MultiNet problem to me. I don't have MultiNet, and thus I have no way to check what's wrong. Could someone please help both Janet and me investigate what is wrong here. The mere fact that typedefs like those cited below generate compilation errors is completelly foreign to me, unless there's an unwise #define somewhere. BTW, Janet, you'd better tell us what MultiNet version is run on your system. Thank you. ------------ >From: "Janet L. Newman" >On Tue, 27 Feb 1996, Richard Levitte - GNU on VMS hacker wrote: > >> I ran accross this yesterday. To fix it, pleaase fetch the latest update: >> ftp.vms.stacken.kth.se:[.GNU-VMS]EMACS-19_28-UPDATES-19960225.TAR-GZ >> unpack into your Emacs source directory, recompile and so on... > >Thanks. I did that, and the build went smoothly for a while, but it >finally aborted with some error messages similar to the one before: > >CC /define=("emacs",HAVE_CONFIG_H 'extra_defs')/include=(local_includes:) /n >ooptimize /standard=vaxc /WARNING=(DISABLE=(ADDRCONSTEXT,GLOBALEXT,LONGEXTERN)) >/prefix=all /NESTED=INCLUDE /debug USER3:[EMACS.EMACS-19_28.SRC]PROCESS.C > /obj = sys$di- >sk:[]PROCESS.obj !/list=sys$disk:[]PROCESS.lis/show=all > >typedef unsigned int u_int; >........................^ >%CC-E-NOLINKAGE, In this declaration, "u_int" has no linkage and has a prior dec >laration in this scope at line number 311 in file SYS$COMMON:[SYSLIB]DECC$RTLDEF >.TLB;3. >at line number 26 in file MULTINET_COMMON_ROOT:[MULTINET.INCLUDE.SYS]TYPES.H;5 > >typedef unsigned short ushort; /* SYS III compatibility */ >........................^ >CC-E-NOLINKAGE, In this declaration, "ushort" has no linkage and has a prior de >claration in this scope at line number 324 in file SYS$COMMON:[SYSLIB]DECC$RTLDE >F.TLB;3. >at line number 27 in file MULTINET_COMMON_ROOT:[MULTINET.INCLUDE.SYS]TYPES.H;5 > > typedef long fd_mask; >.....................^ >%CC-E-NOLINKAGE, In this declaration, "fd_mask" has no linkage and has a prior d >eclaration in this scope at line number 78 in file MULTINET_COMMON_ROOT:[MULTINE >5T.INCLUDE.SYS]TYPES.H;5. >at line number 502 in module TIME of text library SYS$COMMON:[SYSLIB]DECC$RTLDEF >.TLB;3 > > typedef struct fd_set { /* descriptor set */ >................^ >%CC-E-REDEFSTRUCT, In this declaration, the struct "fd_set" is redefined. >at line number 510 in module TIME of text library SYS$COMMON:[SYSLIB]DECC$RTLDEF >.TLB;3 > >%MMS-F-EXEDELPROC, Subprocess terminated abnormally. >%MMS-F-ABORT, For target [.SRC], CLI returned abort status: %X10EE80EC. > > >Once again, is there any way you can help me with this? > >Thanks, >Janet Newman > >+-----------------------+----------------+ >| Janet Newman | | >| jnewman@hmc.edu | You may have | >| East 171 x72019 | just taken | >+-----------------------+ yourself | >| Harvey Mudd College | too | >| 340 E. Foothill Blvd. | seriously. | >| Claremont, CA 91711 | | >+-----------------------+----------------+ > > -- +--------------------------------------------------------------------+ ! Richard Levitte, GNU on VMS hacker ! tel: +46-8-26 52 47 ! ! Spannvägen 38, I ! fax: none for the moment ! ! S-161 43 Bromma ! Internet: levitte@e.kth.se ! ! SWEDEN ! ! +-GNUish VMS-+ You may not add me to a commercial mailing list or send me commercial advertising without my consent! See http://www.e.kth.se/~levitte/anti.html for further reference. ================================================================================ Archive-Date: Thu, 29 Feb 1996 18:40:02 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 29 Feb 1996 9:05:32 -0800 (PST) From: RICK FLOWER Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Message-ID: <960229090532.2285@sdvax2.sp.TRW.COM> Subject: Re: ["Janet L. Newman" : Re: Gnu Emacs build on VMS] >>>>> "vms-emacs-testers@e" == vms-emacs-testers@e kth se writes: > The following report looks like a MultiNet problem to me. I don't have > MultiNet, and thus I have no way to check what's wrong. Could someone > please help both Janet and me investigate what is wrong here. The mere > fact that typedefs like those cited below generate compilation errors > is completelly foreign to me, unless there's an unwise #define somewhere. > BTW, Janet, you'd better tell us what MultiNet version is run on your > system. Thank you. Hmm.. Looks like a problem between DEC-C and Multinet.. We've got Multinet, but not DEC-C.. I've included the offending file that was causing problems below (MULTINET_COMMON_ROOT:[MULTINET.INCLUDE.SYS]TYPES.H;5). Perhaps this file isn't needed when using certain versions of DEC-C?? -- Rick /* * Copyright (c) 1982, 1986 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. * * @(#)types.h 7.1 (Berkeley) 6/4/86 */ #ifndef _TYPES_ #define _TYPES_ /* * Basic system types and major/minor device constructing/busting macros. */ typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; typedef unsigned long u_long; typedef unsigned short ushort; /* SYS III compatibility */ #if !defined(__CADDR_T) && !defined(CADDR_T) #ifndef __CADDR_T #define __CADDR_T #endif /* !__CADDR_T */ #ifndef CADDR_T #define CADDR_T #endif /* !CADDR_T */ typedef char * caddr_t; #endif /* !__CADDR_T && !CADDR_T */ #ifdef __ALPHA /* are we on the ALPHA? */ #ifndef __TIME_T #define __TIME_T 1 typedef unsigned long int time_t; #endif /* __TIME_T */ #else /* Nope */ #ifdef __DECC /* Is this DEC C on the VAX */ #ifndef __TIME_T #define __TIME_T 1 typedef unsigned long int time_t; #endif /* __TIME_T */ #else /* Nope - VAX C */ #ifndef __TYPES #ifndef __TYPES_LOADED typedef long time_t; #define __TYPES #define __TYPES_LOADED #endif /* __TYPES_LOADED */ #endif /* __TYPES */ #endif /* __DECC */ #endif /* __ALPHA */ #define NBBY 8 /* number of bits in a byte */ /* * Select uses bit masks of file descriptors in longs. * These macros manipulate such bit fields (the filesystem macros use chars). * FD_SETSIZE may be defined by the user, but the default here * should be >= CHANNELCNT (SYSGEN parameter) */ #ifndef FD_SETSIZE #define FD_SETSIZE 512 #endif #define CHANNELSIZE 16 /* Size of a channel */ typedef long fd_mask; #define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */ #ifndef howmany #define howmany(x, y) (((x)+((y)-1))/(y)) #endif typedef struct fd_set { fd_mask fds_bits[howmany(FD_SETSIZE, NFDBITS)]; } fd_set; #define FD_SET(n, p) ((p)->fds_bits[(n)/CHANNELSIZE/NFDBITS] |= (1 << (((n)/CHANNELSIZE) % NFDBITS))) #define FD_CLR(n, p) ((p)->fds_bits[(n)/CHANNELSIZE/NFDBITS] &= ~(1 << (((n)/CHANNELSIZE) % NFDBITS))) #define FD_ISSET(n, p) ((!((n) % CHANNELSIZE)) && ((p)->fds_bits[(n)/CHANNELSIZE/NFDBITS] & (1 << (((n)/CHANNELSIZE) % NFDBITS)))) #define FD_ZERO(p) bzero((char *)(p), sizeof(*(p))) #endif /* _TYPES_ */ ================================================================================ Archive-Date: Thu, 29 Feb 1996 19:39:49 MET-1MET DST Sender: owner-vms-emacs-testers-archiver@ctrl-c.liu.se Date: Thu, 29 Feb 96 10:21:28 PST Message-ID: <9602291821.AA12869@tekbspa.tss.com> From: Louise Wholey Reply-To: vms-emacs-testers@e.kth.se To: vms-emacs-testers@e.kth.se Subject: Re: ["Janet L. Newman" : Re: Gnu Emacs build on VMS] > > > The following report looks like a MultiNet problem to me. I don't have > > MultiNet, and thus I have no way to check what's wrong. Could someone > > please help both Janet and me investigate what is wrong here. The mere > > fact that typedefs like those cited below generate compilation errors > > is completelly foreign to me, unless there's an unwise #define somewhere. > > > BTW, Janet, you'd better tell us what MultiNet version is run on your > > system. Thank you. > Perhaps the duplicate typedefs are the result of DEC C not defining them (and thus being defined in the emacs source). Multinet defines all these things. DEC C will not allow duplicate typedefs even if they are identical. Note that Multinet uses the #ifndef _TYPES_ safety latch. DEC C does not define that. - Louise