Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!clyde!burl!ulysses!cbosgd!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: mod.computers.vax
Subject: Re: Missing VMS 4.4 VAXCRT[lg].OLB files
Message-ID: <8609141237.AA18366@ucbvax.Berkeley.EDU>
Date: Sun, 14-Sep-86 08:37:38 EDT
Article-I.D.: ucbvax.8609141237.AA18366
Posted: Sun Sep 14 08:37:38 1986
Date-Received: Mon, 15-Sep-86 02:17:21 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Organization: The ARPA Internet
Lines: 52
Approved: info-vax@sri-kl.arpa


    Our group just brought up VMS4.4 on Microvax/GPX workstations....  What
    I'd like to know is what happened to the VAXCxxxx.OLB files?  Is there a
    difference in the file installed between larger VAX and MicroVAX systems?
[This is probably the most-asked question about VAX C and MicroVMS.  By far.]
Yes, there is a difference.  MicroVMS is designed to be installed on systems
with small disks (e.g., 20 meg RD52's), FROM small disks (RX50's - something
like 23 of them for base MicroVMS!).  It differs from VMS in leaving out
"unnecessary" files - drivers for devices that don't work on MicroVAXes, for
example - and shrinking other files (smaller help files).  MicroVMS contains
essentially NO object libraries - just shareable image libraries.  You notice
this with VAX C for two reasons:

	- Because of C's (lack of) naming conventions, the C library routines
		can't be dropped in to the system library, as the support
		routines for most languages are.  (The FORTRAN routines are
		all there as FOR$xxx, but there would be no way for the C
		compiler to know that "fopen" is supposed to be mapped to
		C$FOPEN.)  Hence, you have to tell the linker explicitly
		where to find the C support routines; for other compilers,
		this is automatic.

	- Until version 2 of VAX C, the C library contained code that couldn't
		be placed in a shareable image library effectively, so the
		library was supplied in object form only.  People thus got
		used to doing things this way, which they never did for the
		other VMS compilers.

There is NO advantage to using the object library, rather than the shareable
library, except in rather rare cases (linking an image that will work on older
versions of VMS, for example - and even then, just having the C library in
object form is often not enough.  Better to ship object files of your code and
link on the target system if this is the problem.)  Using the shareable images
has a number of advantages, including smaller images and the fact that images
pick up bug fixes to the support routines without re-linking.

The only annoyance with shareable image libraries is that there is no way to
specify that one be searched automatically, as you can do for object libraries
with LNK$LIBRARY.  It would be nice if there was a LNK$OPTIONS....  In the
meantime, a command file or perhaps even just a symbol definition should do
the trick.

    Further, Is there a command to given to  create the .OLB from the .EXE
    libraries.
No.  .EXE libraries contain executable code; .OLB's, object code.  You would
need an inverse to the linker.

If for some reasons you REALLY need the object library - and think about this
for a while before deciding you really do - you'll have to get a copy from
some friendly VMS system.
							-- Jerry
-------