From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 3-APR-1991 03:09:52.36 To: ARISIA::EVERHART CC: Subj: Re: Problem Linking with GCC From: RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.92) id AA13947; Sun, 31 Mar 91 22:11:46 EST Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Sun, 31 MAR 91 19:04:19 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27199; Sun, 31 Mar 91 18:52:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Apr 91 01:59:55 GMT From: mips!ptimtc!nntp-server.caltech.edu!eql.caltech.edu!rankin@apple.com (Pat Rankin) Organization: Environmental Quality Laboratory, Caltech Subject: Re: Problem Linking with GCC Message-Id: <31MAR91175955@eql.caltech.edu> References: <1991Mar31.170125.83@kahuna.asd-yf.wpafb.af.mil> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com In newsgroup vmsnet.misc, article <1991Mar31.170125.83@kahuna.asd-yf.wpafb.af.mil>,\ nieland_t@kahuna.asd-yf.wpafb.af.mil writes... > Someone came to our DECUS LUG meeting asking about a problem with GCC. > They are trying to write a DECWindows program and they are compiling the > program with GCC. The program compiles fine, but when they go to link it, > it reports lots of unresolved globals. .. > The symbols it is complaining about are XALLOCNAMEDCOLOR_012C00X, > XBLACKPIXELOFSCREEN_0A0160X, and others very similar. In the VMS version of gas (gnu-as, the assembler used as a backend for gcc), any global symbols which are not all lower case and also don't contain any dollar signs have a string of hex digits apppended to them. Putting that another way, any global symbol which has a dollar sign or has no upper case characters will work as expected; others will not. This misguided attempt to provide case-sensitivity makes it just about impossible to call the MIT version of X routines. However, the VAX bindings version of DECwindows won't have this problem--just the usual C <-> VMS RTL hassles like string descriptors--because they all contain X$, XT$, or DWT$ prefixes. > The gentleman said that if he used the previous version of GCC assembler, > he didn't get the link errors, just a "no user transfer address" message. > He is using version 1.37.1 of GCC that was distributed on the DECUS VMS > Startup Collection. He's probably mistaken. This isn't new behavior for gas, and more recent versions (latest is gcc 1.39 + gas 1.38.1) still work [or not :-] the same. gas 1.34 and 1.22 both were the same; those were the other versions I could track down to verify it. A possible work-around would be to create stub routines with the mixed case names that just call similarly named routines which are all lower case. That interface module should avoid the X include files, I suspect, so that it won't have any conflicting macros. Something along the following ought to work (warning, this is untested)... |void *xopendisplay(const char *); |void *XOpenDisplay(const char *foo) { return xopendisplay(foo); } The lowercase name would be transformed into "XOPENDISPLAY", which is the actual name in the VMS shareable image. The mixed case name would be "XOPENDISPLAY_04C000X", which would be what the regular user code was really trying to call. Another possible work-around would be a set of macros which forced everything into lower case. For instance, an include file containing |#define XOpenDisplay xopendisplay ... Just include that before and such. The lower case names would result in resolvable symbols at link time. There could easily be conflicts with other macros though. Pat Rankin, rankin@eql.caltech.edu