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"?