Preparation for moving enlightenment and conduct into new source
file insight.c. Right now it's a stub that shouldn't break anything
whether included or omitted. Once makefiles and project files have
been updated to compile and link it, the actual code will be moved.
unix/Makefile.src has been updated;
vms/Makefile.src and vmsbuild.com have been updated but not tested.
A copyright header inserted last spring uses the wrong format for a
DCL comment and triggers a couple of warnings about invalid commands.
Some linker hackery added a long time ago draws complaints from the
linker on IA64. This was noticed during the release cycle for 3.6.0
but then went unaddressed.
Apparently I exited emacs without saving and the revised vmsbuild.com
ended up as a backup file that 'git nhadd' wouldn't see. This was
supposed to be included in the patch committed several hours ago....
First reported two years ago, then again this week by someone else
who didn't go through the web contact page (so no new #H number or
bugzilla entry). Using vmsbuild.com to build on VAX complains about
not being able to resolve a bunch of functions--it's basically
trying to build the full program using only the code supplied by
sys/vms/vmsmain.c. The original report mentioned a workaround and
was also dealing with a second issue (already fixed post-3.6.0) that
I incorrectly guessed was responsible for the linking problem. This
report had the correct linker magic to fix the linking issue.
I'm still not sure whether the order of /Library and /Include after
the name of an object library file on a LINK command line matters.
In a linker options file, which vmsbuild.com constructs and uses,
/Include needs to come first so that the contents of the library are
searched after the explicitly included object modules are processed.
Building with the Makefiles (using DEC's MMS or some versions of
freeware MMK) doesn't collect the object files into a library so was
never affected by this. And the linker options ordering issue is
apparently specific to the VAX/VMS linker; vmsbuild.com run on Alpha
and on IA64 linked 3.6.0 successfully without this fix.
Update vms/install.com (rather than Makefile.top) to install the new
data file for the 'whatdoes' command.
Also, the 3.6.0 distribution puts version number 3.5.0 into vms
binaries (all the programs, not just nethack itself). It's something
observable with native tools without running the program, nothing to
do with nethack's 'v' command which gets its version number from
patchlevel.h via makedefs.
Update the command procedure that can be used to compile and link
everything. The sys/vms Makefiles still need updating.
I added 'tribute' to the command procedure used to create and populate
the plaground directory but am not able to test it.
The preliminary implementation of PANICTRACE on VMS had a "Fixme"
that this fixes, and a "TODO" that this makes moot, but the main reason
for this patch is that vmsmisc.c had been changed to call vms_define(),
which resides in vmsunix.c. Since vmsmisc.obj is linked into progarms
in util/ and vmsunix.obj isn't, enabling PANICTRACE caused linking
problems for those. This moves the code that wants to call vms_define()
into vmsunix.c (despite the fact that it's not even vaguely related to
Unix emulation), so that it only matters to nethack and doesn't impact
the utility programs anymore.
This uses a VMS facility called LIB$INITIALIZE to call code before
main() starts. It's rather messy--at least when written in something
other than assembler or Bliss--and shouldn't be needed for nethack,
but I couldn't figure out how to trap the condition signalled by
lib$signal(SS$_DEBUG) when the debugger isn't available to do so, so I
needed a way to make issuing that signal be conditional upon debugger
availability. One of the arguments passed to LIB$INITIALIZE-invoked
routines contains information that makes if feasible to deduce whether
the debugger is available.
Even when PANICTRACE is disabled, that's useful for handling abort
due to panic while in running in wizard mode.
I hadn't tried the build script vmsbuild.com in a long time....
vmsbuild.com wasn't compiling src/sys.c;
vmsbuild.com and Makefile.src+Makefile.utl had some linking discrepancies;
Makefile.top, Makefile.dat, Makefile.doc - replace old SCCS id/date/rev
comment with current cvs one (done for .src & .utl a month or so back);
config1.h - running DEC C in VAX C compatability mode to test linking
yielded a diagnostic about signed in the schar typedef for every file.
The fix for #H1409 a couple of days ago included updates for
sys/vms/Makefile.* but not vmsbuild.com. I thought the latter didn't
need any, but was mistaken; vmsfiles.c needs to be compiled early in
order for vmsfiles.obj to be present in the object library when makedefs
gets linked.
