[comp.os.vms] Linking against RTLs

AWalker@RED.RUTGERS.EDU (*Hobbit*) (07/29/87)

[Apparently my first msg about this got lost.]

I want to link images that reference VMSRTL and LIBRTL such that the
code I use from the library winds up *in the image*, not simply mapped
at activation time.  This is so the resultant image can be run on a site
with a lower version of VMS.  [No flames about why you shouldn't do that --
if the image doesn't use newer system calls or the like it'll be fine.]
I've ding near shredded the linker manual trying to find out how to
convince LINK to include the code in my image.  Can it be done, and if
so, how??  The idea here is to generate images that have *no* shared-library
dependencies and can run "anywhere" [in the 4.x universe, I suppose].

Quickie WRT sys$announce and legal issues:  Probably the best idea is
to use sys$announce to tell people which box they're talking to [i.e. just
the name of the facility or something] and use sys$*welcome* for just
that -- once they've legally and properly logged in, *then* welcome them
with open arms and long announcements.  Everyone else can only see a little
bit of writing on the cold wall that keeps them out...

_H*
-------

gkn@SDS.SDSC.EDU (08/01/87)

	From:	 *Hobbit* <AWalker@RED.RUTGERS.EDU>
	Subject: linking against RTLs
	Date:	 29 Jul 87 03:47:20 EDT
 
	[Apparently my first msg about this got lost.]
 
	I want to link images that reference VMSRTL and LIBRTL such that the
	code I use from the library winds up *in the image*, not simply mapped
	at activation time.  This is so the resultant image can be run on a site
	with a lower version of VMS.  [No flames about why you shouldn't do that --
	if the image doesn't use newer system calls or the like it'll be fine.]

$ Link/NoSYSSHR ...

Page LINK-132.

gkn
--------------------------------------
Arpa:	GKN@SDSC.ARPA
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (27.1)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA 92138
AT&T:	619.534.5076

ted@blia.BLI.COM (Ted Marshall) (08/02/87)

In article <12322163796.34.AWALKER@RED.RUTGERS.EDU>, AWalker@RED.RUTGERS.EDU (*Hobbit*) writes:
> I want to link images that reference VMSRTL and LIBRTL such that the
> code I use from the library winds up *in the image*, not simply mapped
> at activation time.  This is so the resultant image can be run on a site
> with a lower version of VMS.

The linker will not move modules from a shareable image into the executable.
However, most, if not all of the standard RTL routines are also in STARLET.OLB.
Thus, if you link /NOSYSSHR/SYSLIB, you will get the routines in your
executable as you desire. Note, the STARLET.OLB shipped with Micro-VMS is
much cut down and won't do the job. Note also that other user callable
shareable images, for example, LBRSHR.EXE for accessing a library file, do
not have .OLB forms shipped with VMS so you are stuck.

Another way to support down rev VMS systems is as follows: decide on the lowest
version of VMS you want to support. Go to the VMS distribution for that version
(you did keep the old distributions, didn't you? :-), extract all of the
shareable images that went into SYS$SHARE and put them in a private directory.
When you go to link your application, link /NOSYSSHR and reference the
necessary shareable images from the private directory in your .OPT file.
When the application is run, the shareable images will be referenced from
SYS$SHARE and it will be just like you linked on that lower version.

Final note: the execuable file format changed slightly from V3 to V4. I don't
think there is any way to link under V4 and produce a V3 compatable image
unless you run the V3 linker.

-- 
Ted Marshall       ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU
Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

"James_A._Gray.OsbuSouth"@XEROX.COM (08/03/87)

Question:

I want to link images that reference VMSRTL and LIBRTL such that the
code I use from the library winds up *in the image*, not simply mapped
at activation time.  This is so the resultant image can be run on a site
with a lower version of VMS.  [No flames about why you shouldn't do that
--
if the image doesn't use newer system calls or the like it'll be fine.]
I've ding near shredded the linker manual trying to find out how to
convince LINK to include the code in my image.  Can it be done, and if
so, how??  The idea here is to generate images that have *no*
shared-library
dependencies and can run "anywhere" [in the 4.x universe, I suppose].

Answer:

If you are NOT running on a MircoVAX then all you need to do is to
include the qualifier /NOSYSSHR on your link command.  If you ARE
running on a MicroVAX then you will need to get access to the libraries
that are distributed with standard VMS unless you use a small enough
subset of the VMS libraries; if you are then just use /NOSYSSHR.  Not
all of the modules are there in the object libraries for MicroVMS since
it was felt that they take up too much room (per the documentation).

The way to insure that you are not linked to any shareable libraries
that you don't want to be, is to do an ANALYZE/IMAGE of the .EXE files
and check the shareable image list near the end.

	Jim

jeh@crash.CTS.COM (Jamie Hanrahan) (08/03/87)

Another poster mentioned the /nosysshr option to the linker and its 
limitations.  If you can't live with the limitations, one useful workaround
is to ship the object files and link them on the target machine.  DEC does
this for many of their layered products; in fact, one of the example 
product installation command procedures in the "Developer's Guide to 
VMSINSTAL" illustrates this, though it isn't specifically mentioned in 
the text.  The handiest trick is to put all the objects into one or a
few object libraries and use /include to pull out the main program
mo.St.St.

"Bruce_G._Kahler.rochX2"@XEROX.COM (08/05/87)

I have a somewhat naiive question on the discussion of the above topic.
If the purpose of the RTL routines is to provide an interface into the
VMS environment in which the program is running, then even if you can
include all the code in the image file, don't you run the risk of
incompatability between the RTL routines where you linked the program
and the system where it is run?  Wouldn't a safer approach be to port
object modules to the target sytem and re-link there as part of "product
installation"?