jayb@zeus.tek.CSNET ("Jay Beck - Tektronix Inc./CAE/Silicon Design Produ) (09/08/86)
Our group just brought up VMS4.4 on Microvax/GPX workstations. After successfully completing the VMS C v2.2 procedure we started got an error from the linker stating that it couldn't find the file SYS$LIBRARY:VAXCRTL.OLB which it was told to look for by having defined logical LNK$LIBRARY. This was done according to the instructions in the C 2.2 installation guidebook. It is my understanding that the files SYS$LIBRARY:VAXCRTL.EXE and VAXCRTLG.EXE are put on the system when VMS4.4 is installed. We have successfully used the .EXE files to run our C code by creating a file named SYS$LIBRARY:OPTIONS_FILE.OPT in which we placed the single line: SYS$LIBRARY:VAXCRTL.EXE. Then deleted the logical LNK$LIBRARY via DEASSIGN LNK$LIBRARY, and then used the linker command: LINK/EXEC=x x.OBJ,SYS$LIBRARY:OPTIONS_FILE/OPT. This however is just another solution. 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? Further, Is there a command to given to create the .OLB from the .EXE libraries. Your input would be appreciated...Thanks. ------------------------------------------------------------------------------- tektronix!zeus!jayb Jay Beck (503) 629-1485
LEICHTER-JERRY@YALE.ARPA (09/14/86)
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
-------LLACROIX%carleton.edu@RELAY.CS.NET (Les LaCroix) (09/19/86)
In a recent note to jayb%zeus.tek.csnet@csnet-relay.csnet (cc to info-vax) regarding VAXCRTL object libraries vs the corresponding shraed images, you state: > 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. Two small objections here: 1) You get smaller images and RTL bug fixes, all w/o relinking. You also get an extra image to be activated every time you run your application. In most cases that's not worth worrying about. Then there are those rare times when it *does* matter. 2) In addition to the bug fixing that comes along with VMS updates, it's not unheard of to see new bugs introduced. Yes, even from DEC, and yes in the RTLs. A product of my employer's was hit with such a problem with VMS 4.4. Fortunately the problem was only annoying and had no consequential impact for our customers. Even more fortunate is the fact that these kinds of problems are very rare. Conclusion: know your options and the implications, then use the shared images unless you have a *really* good reason to do otherwise. > 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. True, but sometimes you can fake it by creating a Shared Image Library which contains references to the shared images you want to link against. Your program still gets linked to the shared images, but you can usually avoid a Linker Options file. Unfortunately, there have been documented problems in the past with shared image libraries which refer to VAXCRTL.EXE. I don't know if the problems still exist in VMS 4.4. Les LaCroix | csnet: llacroix@carleton.edu SPSS, Inc. | uucp: ...{ihnp4,decvax}!stolaf!ccnfld!llacroix 402 Washington Street | ...ihnp4!gargoyle!spsspyr!lacroix Northfield, MN 55057-2027 | "A dog is a dog until he faces you. Then he is Mr. Dog." - haitian farmer
LEICHTER-JERRY@YALE.ARPA (09/21/86)
[The discussion involved the tradeoffs between using the object and shareable
image versions of the C library.]
1) ... You also get an extra image to be activated every time you run your
application. In most cases that's not worth worrying about. Then there
are those rare times when it *does* matter.
Hmm...I guess this COULD be an issue, but if VAXCRTL.EXE is installed, I think
it's likely to be a tradeoff between one extra image activation and extra I/O
for a larger image - which could easily go either way.
2) In addition to the bug fixing that comes along with VMS updates, it's
not unheard of to see new bugs introduced. Yes, even from DEC, and yes in
the RTLs. A product of my employer's was hit with such a problem with VMS
4.4. Fortunately the problem was only annoying and had no consequential
impact for our customers. Even more fortunate is the fact that these
kinds of problems are very rare.
There's a work-around: Keep a copy of the old RTL around, as VAXCRTL_OLD, for
example. Then ASSIGN wherever:VAXCRTL_OLD VAXCRTL before running the program.
This is the best general solution for all sorts of cases where stuff isn't
QUITE upward compatible.
Conclusion: know your options and the implications, then use the shared
images unless you have a *really* good reason to do otherwise.
Absolutely.
True, but sometimes you can fake it by creating a Shared Image Library
which contains references to the shared images you want to link against.
Your program still gets linked to the shared images, but you can usually
avoid a Linker Options file. Unfortunately, there have been documented
problems in the past with shared image libraries which refer to
VAXCRTL.EXE. I don't know if the problems still exist in VMS 4.4.
Yes, there was some sort of annoying problem with the I/O library; stuff ended
up being based because of a non-PIC reference. It may very well be fixed by
now, though I can't say I've tried it. Certainly would be nice if it were.
"A dog is a dog until he faces you. Then he is Mr. Dog." - haitian farmer
Neat saying.
-- Jerry
-------LLACROIX%carleton.edu@RELAY.CS.NET (Les LaCroix) (09/23/86)
[The discussion started talking about pros and cons of linking against a shared image vs. linking against the equivalent object library. We agree that in general it is better to link against the shared image, as long as you know about the ramifications; we quibble about the ramifications.] The first three lines are mine, the second three are your response: > 1) ... You also get an extra image to be activated every time you run your > application. In most cases that's not worth worrying about. Then there > are those rare times when it *does* matter. > Hmm...I guess this COULD be an issue, but if VAXCRTL.EXE is installed, I think > it's likely to be a tradeoff between one extra image activation and extra I/O > for a larger image - which could easily go either way. If VAXCRTL is installed shared and your application isn't, then maybe. If it's not installed shared you will have no additional I/O when the routines reside in your own image. Actually, you will probably have less paging I/O since VAXCRTL.EXE seems to be laid out in a helter-skelter way. Look at a full link map for K&P's first C program ("hello, world\n") when you link against VAXCRTL.EXE. VAXCRTL socks you with 10 image sections which have to be resolved at activation time. Looking further at that link map, you will see that it's not just one extra image activation. Linking against VAXCRTL.EXE also links you against LIBRTL (no surprise), SMGRTL, FORRTL and MTHRTL. Presumably the last three support Curses and the C math library. Not _quite_ as bad as linking against DTRSHR... Don't forget all of the trouble it takes to activate a (shared) image, even when it's installed. There are still lots of pages to map and addresses to fix up, more when you consider all of the extra RTLs being brought in. Les LaCroix | csnet: llacroix@carleton.edu SPSS, Inc. | uucp: ...{ihnp4,decvax}!stolaf!ccnfld!llacroix 402 Washington Street | Northfield, MN 55057-2027 | "Open the pod-bay doors, HAL." - Arthur C. Clark