lars@ACC.ARPA (01/03/86)
I need to create a distribution kit for a layered software product. The kit is intended to install with VMSINSTAL and it includes an IVP released in executable form, since I don't want to force the customer to license a language processor for a program that he should have no need to compile. (Specifically, the IVP is written in VAX C). In the old days, this would work fine. I would package the kit on release X.Y of the operating system and require the customer to have "Release X.0 or later". These days, with even-numbered minor releases being feature releases, it doesn't work any more. The previous plociy was that images in VMS would be re-linked only for major releases, and bugfixes in between were done with the PATCH utility. Now, "feature" releases issue new images with changed minor IDs. The result of this is, that if I package my product kit on VMS 4.2, the IVP references SYS$SHARE:LIBRTL of VMS 4.2, but when my customer installs the kit on VMS 4.1, the image activator returns an IMAGE VERSION MISMATCH, and the execution fails. (Because LIBRTL is linked with GSMATCH=LEQUAL). I cannot re-link the program as part of the installation procedure, because VAXCRTL.OLB is not a part of "basic" VMS. Short of patching LIBRTL.EXE to fake GSMATCH=ALWAYS, what can I do ? Is there a link option that I can invoke to make my IVP.EXE include a private copy of the shared libraries available at link time, rather than depend on the version on the target system ? I should think that this problem must have come up within DEC's layered product groups as well, and I'd appreciate it if someone has a solution. / Lars Poulsen Advanced Computer Communications <Lars @ ACC.ARPA> ------
LEICHTER-JERRY@YALE.ARPA (01/04/86)
[In order to produce an IVP that works on earlier versions of VMS,]
Is there a link option that I can invoke to make my IVP.EXE include a
private copy of the shared libraries available at link time, rather than
depend on the version on the target system ?
/ Lars Poulsen
Advanced Computer Communications
<Lars @ ACC.ARPA>
/NOSYSSHR does exactly what you want.
-- Jerry
-------info-vax@ucbvax.UUCP (01/06/86)
> ... > I cannot re-link the program as part of the installation procedure, > because VAXCRTL.OLB is not a part of "basic" VMS. My understanding (from the VAX C internals session at the Anaheim DECUS), is that VAXCRTL will be distributed with VMS in future releases -- not with the VAX C updates. If true, that may enable you to work around your problem.