Building C programs for older versions of VMS

[Jeremy Begg]

Hi,

My primary software development system is a cluster which has an Alpha running VMS 8.3 and an Integrity server running VMS8.3.1H1. I am developing some software which needs to be supported as far back as Alpha VMS V6.1.

According to the C Run-Time Library reference manual I need to do the following:

$ dir = "D2:[VMSLIB.ALPHA.V61]"
$ DEFINE DECC$SHR 'dir'DECC$SHR.EXE
$ CC /DEFINE="__VMS_VER=60100022" MYPROG
$ DEFINE ALPHA$LIBRARY 'dir'
$ LINK MYPROG

The D2:[VMSLIB.ALPHA.V61] directory contains a copy of the SYS$LIBRARY directory from a VMS 6.1 system disk.

The problem is that the C compiler appears to require a current DECC$SHR to work: when I run the compiler after defining DECC$SHR as above I get the error

%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when DECC$COMPILER references DECC$SHR

The C Run-Time Library reference manual says that the definition of DECC$SHR is necessary because the compiler "uses a table from DECC$SHR to perform routine name prefixing", but is this true?

(I think the above has worked in the past, several years ago, so perhaps recent versions of the compiler have been linked differently to how they used to be.)

Thanks,
Jeremy Begg

[abrsvc]

The typical method of supporting multiple versions is to develop the code on the "oldest" version. OpenVMS provides upwards compatibility. This means that code generated on older versions will continue to work on newer versions unchanged (for the most part). At most, a relink will be necesary. Attempting to compile/link code on a vewer version is dangerous. If you have a system disk with an older OS version, use that to create the V6.1 executable. The actual C code may be the same or require a few version specific changes, but for the most part, this will be the safest path.

Dan

[John Reagan]

1) You'll want to undefine the DECC$SHR before the LINK command. You want the linker to use the system shareables when activativing (via SYS$SHARE).

2) For the compile, the reason for the DEFINE is for the compiler to figure out the right prefix list buried in the image.

Try pointing to the saved DECC$CRTLMAP.EXE instead.

$ DEFINE DECC$CRTLMAP 'dir'DECC$CRTLMAP.EXE

[Craig A Berry]

Just from glancing at the CRTL headers, I would think you would need __CRTL_VER as well as __VMS_VER defined, though perhaps the compiler defines the former in terms of the latter automatically.  

As far as finding the right prefixes, perhaps CC/PREFIX=RTL="name" would do the trick?

[John Gillings · Accepted solution]

Jeremy

(for completeness I'm posting the response I mailed you while the fora were off line - with the finest technology on the planet, how come it took HP a week to transfer a bit of text?? and how come something as basic and fundamental as PASTE no longer works??? the only way I've found so far is via a dialog box)

 No reason you shouldn't be able to do this on any version. Try it this way around:

$ CC /DEFINE="__VMS_VER=60100022" MYPROG
$ V61dir = "D2:[VMSLIB.ALPHA.V61]"
$ DEFINE/USER DECC$SHR 'V61dir'DECC$SHR.EXE
$ DEFINE/USER ALPHA$LIBRARY 'V61dir'
$ LINK MYPROG

  I wouldn't expect the C compiler itself to work with the older RTL. You only need the redirection while you're linking (or running). The linker doesn't reference DECC$SHR, so there shouldn't be any version mismatches. I've also used /USER so it will automatically deassign after the LINK.

Same for ALPHA$LIBRARY.

I've also changed the symbol to "V61dir" as I don't think it's a good idea to define "DIR" as anything other than a DIRECTORY command.

[Jeremy Begg]

As (almost!) always John G, your solution works for me. Thanks!