Emacs for VMS x86
Posted: Tue May 02, 2023 6:46 am
Is there anyone looking at building Emacs for VMSx86?
/Daniel
/Daniel
The official board to discuss OpenVMS-related topics
https://forum.vmssoftware.com/
Code: Select all
=*== MicroEMACS 3.12 L:1 C:1 (ASAVE) == hello.c == File: hello.c ===============
Code: Select all
UEMACS-4 ┬AIX
│ │ ├AMIGA
│ │ ├ATARI
│ │ ├BRIEF
│ │ ├BSD
│ │ ├CMD
│ │ ├DGUX
│ │ ├DOC
│ │ ├FMR
│ │ ├FREEBSD
│ │ ├H
│ │ ├HP150
│ │ ├HPUX
│ │ ├HTMLHELP ─HTML
│ │ ├I55
│ │ ├LINUX
│ │ ├MACOSX ─MEMACS_X*┬PROJECT_*┬XCSHARED*
│ │ │ │ └XCUSERDA*◆
│ │ │ └XCUSERDA*─PETER_XC*◆
│ │ ├MPE
│ │ ├MSWIN ┬BCPP
│ │ │ ├BCPP55
│ │ │ ├MSC
│ │ │ └VS2017
│ │ ├NEC
│ │ ├NT ─BCPP55
│ │ ├OS2
│ │ ├PCDOS ┬ANSI
│ │ │ ├ANSI16M
│ │ │ ├DOS16M
│ │ │ ├IC
│ │ │ ├M6
│ │ │ ├M7
│ │ │ ├MSC
│ │ │ ├TURBO ─BIN
│ │ │ └XVT ─BIN
│ │ ├SRC
│ │ ├SUN ┬CC
│ │ │ └GCC
│ │ ├VMS
Code: Select all
%ILINK-W-USEUNDEF, undefined symbol TERM referenced
section: $CODE$
offset: %X0000000000000EFF
module: WINDOW
file: DKA400:[PRODUKTE.2-5000.02.UEMACS-4.SRC]WINDOW.OBJ;1
Are you going with the version that build on VMS VAX/Alpha/Itanium and just trying to build it on VMS x86-64?
The first will probably be the sources from the freeware CD. On the freeware CD there are sources for/based on Emacs 21.2. It's more or less a snapshot of a development environment. If you build and run Emacs it identifies itself as version 21.2.1. Unfortunately there seems to be no matching source code for this version on Savanna. The Itanium specific sources will not really help with the x86 port. The Alpha sources seem to be the base to start with.
hb wrote: ↑Wed May 03, 2023 6:50 amThe first will probably be the sources from the freeware CD. On the freeware CD there are sources for/based on Emacs 21.2. It's more or less a snapshot of a development environment. If you build and run Emacs it identifies itself as version 21.2.1. Unfortunately there seems to be no matching source code for this version on Savanna. The Itanium specific sources will not really help with the x86 port. The Alpha sources seem to be the base to start with.
I did a cross tools build, some time ago (https://groups.google.com/g/comp.os.vms ... 0GuhReAQAJ). But when I recently tried a native x86 build, I ran into unexpected problems. There is specific VMS code, which either needs to be made compatible with current C headers, or needs to be removed. It's not obvious which way is easier to get a somehow working version. Unfortunately I do not have the time to work on this. But using the sources which compiled for VMS may still be easier than porting the current Emacs sources.
Code: Select all
> It compiles and link after change in VMSLINK.COM
> (SYS$SHARE:VAXCRTL/SHARE ==> SYS$SHARE:LIBRTL/SHARE).
You're not using VAX C, so I can see why removing the reference to
VAXCRTL.EXE makes sense. Did you actually need to specify
"SYS$SHARE:LIBRTL/SHARE"?
Is there something in the builders which decides that you _are_ on a
VAX, possibly because it doesn't recognize the x86_64 architecture? In
many cases, when Alpha (and/or IA64) arrived, people added tests for
Alpha (and/or IA64), when the smart move would have been to test for
VAX or non-VAX rather than for specific non-VAX architectures (of which
there's now another one).
and "It" is what?
Code: Select all
$ pipe unzip -v [.EMACS]EMACS21_2.ZIP |search sys$pipe VMSLINK
39 Defl:N 34 13% 10-21-2004 12:15 88925363 emacs/build/vms/vmslink.opt
$ unzip -p [.EMACS]EMACS21_2.ZIP emacs/build/vms/vmslink.opt
MULTINET:MULTINET_SOCKET_LIBRARY/SHARE
Code: Select all
$ ty [...]VMSLINK.OPT
WORK:[USER.EMACS.ALPHA.EMACS.BUILD.VMS]VMSLINK.OPT;1
UCX$LIBRARY:TCPIP$LIB/LIBRARY
WORK:[USERER.EMACS.IA64.EMACS.BUILD.VMS]VMSLINK.OPT;1
UCX$LIBRARY:TCPIP$LIB/LIBRARY
WORK:[USER.EMACS.X86.EMACS.BUILD.VMS]VMSLINK.OPT;1
UCX$LIBRARY:TCPIP$LIB/LIBRARY
$
Code: Select all
> https://github.com/william8000/microemacs
Ok. Lame (in more than one way) test in vmslink.com:
> $ if f$getsyi("VERSION") .lts. "V8" then goto USEVAXCRTL
V87 $ write sys$output f$getsyi("VERSION")
E9.2-1
V87 $ write sys$output f$getsyi("VERSION") .lts. "V8"
1
1. Stripping the first character off that version string would have
helped with the "E" v. "V" problem.
2. As mentioned above, VAXCRTL.EXE should be used with VAX C, _not_
with DEC C, making it unlikely to be useful on any (")modern(")
VAX system. The VMS version does not identify the compiler being
used, making that test inappropriate, and VAX C is seriously
unlikely to be used these days. Which makes the whole USEVAXCRTL
section an antique waste of space. (I claim.)