home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / vms / 14266 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.4 KB

  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!mips!decwrl!deccrl!news.crl.dec.com!rdg.dec.com!adserv.enet.dec.com!winalski
  2. From: winalski@adserv.enet.dec.com (Paul S. Winalski)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Linking C programs
  5. Message-ID: <1992Aug28.165358.1481@rdg.dec.com>
  6. Date: 28 Aug 92 16:53:58 GMT
  7. References: <01GO244CRQ7K8WWQ8Q@MARICOPA.EDU>
  8. Sender: news@rdg.dec.com (Mr News)
  9. Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
  10. Organization: Digital Equipment Corporation, Nashua NH
  11. Lines: 57
  12.  
  13.  
  14. In article <01GO244CRQ7K8WWQ8Q@MARICOPA.EDU>,
  15. shoecraf@mc.bitnet (Steve Shoecraft) writes:
  16.  
  17. |>    A short time ago, I saw a response to one of these questions which pointed
  18. |>out where the REAL problem is, and why we need to do this in the first place.
  19. |>It was pointed out that since the CRTL wasn't in the sharable image library,
  20. |>IMAGELIB.OLB, and therefore, we must provide a pointer to it implicitly. Well,
  21. |>why not put it there?? To do this, just add it to the image library:
  22. |> 
  23. |>        $ SET DEF SYS$LIBRARY
  24. |>        $ LIB/SHARE IMAGELIB SYS$SHARE:VAXCRTL.EXE
  25. |> 
  26. |>    Now you have to remove the logical name pointer to VAXCRTL.OLB. Do a SH
  27. |>LOG LNK* <enter>. There will be a reference that looks something like this:
  28. |> 
  29. |>        LNK$LIBRARY = "SYS$LIBRARY:VAXCRTL"
  30. |> 
  31. |>    If you have curses and/or g_float support, it may be LNK$LIBRARY_1 or _2.
  32. |>be sure to DEASS/SYS the logical name that points to VAXCRTL. Also, you might
  33. |>also wish to remove/comment out the entry which defines it in the startup
  34. |>command procedure so that if the system is rebooted, users will not go back
  35. |>to linking against the regular library.
  36. |>    If anyone out there might have any comments or warnings on this please let
  37. |>me know... As yet, I have not seen/heard of any problems by doing this...
  38.  
  39. DON'T DO IT!!!  IT DOESN'T WORK PROPERLY!!
  40.  
  41. There are two problems with putting VAXCRTL.EXE into IMAGELIB.OLB:
  42.  
  43. 1) VAXCRTL.EXE's global symbols don't conform to VMS naming conventions--they
  44.    do not have a facility prefix.  If you put VAXCRTL.EXE into IMAGELIB, then
  45.    programmers or products on your system using languages other than C may
  46.    encounter errors when linking.  VAXCRTL.EXE defines some very popular names,
  47.    such as "abort", "open", "close", "read", "write", as global symbols.  These
  48.    names are not reserved words in many programming languages.
  49.  
  50.    Bottom line:  If you put VAXCRTL.EXE into IMAGELIB, other things you have
  51.    on your system may fail to link properly.
  52.  
  53. 2) The VMS Linker has traditionally had a problem resolving common block
  54.    PSECTs (VAX C extern and global variables) that come from shareable images
  55.    retrieved from a shareable image library.  This problem doesn't occur if
  56.    the Linker gets the same shareable image due to its being referenced
  57.    outside the context of a shareable image library.  This bug can cause
  58.    multiple copies of important things like errno, stdin, stdout, and stderr
  59.    to be in your program.  You can get incorrect and unpredictible results.
  60.  
  61.    Bottom line:  If you put VAXCRTL.EXE into IMAGELIB, the C RTL doesn't work
  62.    properly.  It can fail in obscure ways under equally obscure circumstances.
  63.  
  64. There is a replacement C RTL, the DEC C RTL, in the works for VMS.  It will
  65. ship with the next major VMS release.  It *is* IMAGELIB-compatible.  When the
  66. DEC C RTL ships, all us C programmers can finally throw away our options
  67. files.
  68.  
  69. --PSW
  70.