🚀 go-pugleaf

In article <1992Apr8.101519.16812@yang.earlham.edu>, irac@yang.earlham.edu (Ira Carmel@Waycoolone) writes:
|>Thanks everyone for your help with the C libraries stuff. My .exe files are now
|>small and nice. I have another question concerning these executable files
|>though. One of my fellow system hacker/helper people thinks that by linking the
|>.exe files with the shareable .exe options will make it so that we will have to
|>relink the files if we upgrade the system. By linking with the libraries like
|>we had them, the files would be 'more portable?' because the linker would
|>include all of the neccessary io routines?

The DEC shareable images are built with transfer vectors at the beginning
of the image to eliminate just this problem. I have programs linked with
shareable images from VMS V3.2 which still run under VMS V5.5. Being able
to do this was one of the design goals of VMS.

One advantage to linking with shareable images is that you get any bugfixes
supplied with the upgrade without having to relink your programs. The way
your hacker/helper person suggests doing things would require relinking to
get these bugfixes, which is just what he's trying to avoid.

I strongly suggest your hacker/helper person read some of the documentation
before issuing gloomy predictions.

|>SO now I like files like this-
|>
|>$ define vaxc$include sys$library
|>$ define link_opt options_c_link.opt
|>
|>where the options_c_link.opt file contains
|>sys$share:vaxcrtl.exe/share
|>
|>My link command is
|>$ link myfile,link_opt/opt    (how does this sound?)

I don't bother with the logical name, but otherwise this is exactly
what I do. I have a collection of link options files, one for each
common configuration (just VAXCRTL, TWGLIB and VAXCTRL, etc).

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.