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