carl@CITHEX.CALTECH.EDU.UUCP (01/18/87)
Yes, if you want to avoid using shareable images, you use the object library
SYS$SHARE:VAXCRTL.OBJ. No, you probably don't have the particulars correct:
There are very few good reasons for avoiding the use of shareable images, and
two very good reasons to do just the opposite. The latter are:
1) You use memory more efficiently. Once one image forces the loading
of the code in a shareable image, that code stays in memory until
nobody is using it, and you don't have to load any other copies of
it. Thus you reduce page faulting, and DISK/IO.
2) You use less disk space. Images linked with the object library
each contain a copy of the routines they use from that library.
When linked with a shareable image, they contain a bit of information
to let them find the entry points in the shareable image. This
can make the difference, say, between a 7-block executable and one
that is well over 70 blocks in size, for a small program. For larger
programs, if they make extensive use of the system libraries, the
difference can be even greater. If you've got a fairly standard
uVAX, one of the problems you're probably facing is the limited
amount of disk space available to you.
Now, as to the reasons for wanting to link with the object library:
1) You want to be able to move the code to a machine that doesn't
have the library:
A) The other system has a different version of the library:
In this case, you should move the object modules, and link
them on the other system. It is not guaranteed that one
version of the libraries will work on a system running a
different version, even if you link with the object library
and use the /NOSYSSHR flag. DON'T DO IT.
B) The other system doesn't have ANY version of the library:
The VAX C Run Time Library is now a part of the basic VMS
package. This is no longer an excuse for what you're proposing.