From:	CRDGW2::CRDGW2::MRGATE::"SMTP::PREP.AI.MIT.EDU::HELP-GCC-REQUEST" 18-MAR-1991 20:38:10.57
To:	ARISIA::EVERHART
CC:	
Subj:	Re: Building emacs under VMS using gcc

From:	help-gcc-request@prep.ai.mit.edu@SMTP@CRDGW2
To:	Everhart@Arisia@MRGATE

Received:  by crdgw1.ge.com (5.57/GE 1.91)
	 id AA23829; Mon, 18 Mar 91 20:28:05 EST
Received: by life.ai.mit.edu (4.1/AI-4.10) id AA04751; Mon, 18 Mar 91 19:31:01 EST
Return-Path: <donn@milton.u.washington.edu>
Received: from milton.u.washington.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04682; Mon, 18 Mar 91 19:28:13 EST
Received: by milton.u.washington.edu
	(5.61/UW-NDC Revision: 2.1 ) id AA09290; Mon, 18 Mar 91 16:28:07 -0800
Date: Mon, 18 Mar 91 16:28:07 -0800
From: Donn Cave <donn@milton.u.washington.edu>
Message-Id: <9103190028.AA09290@milton.u.washington.edu>
To: gnu-gcc-help@prep.ai.mit.edu
Subject: Re: Building emacs under VMS using gcc

From: ian@sibyl.eleceng.ua.OZ (Ian Dall)
Subject: Building emacs under VMS using gcc
|
|I am trying to build emacs (18.55) on a VMS 5.4 machine using gcc. We
|do not have VAX C. There seems to be some differences in the include
|files compared to VAX C, but I am sorting all those out gradually.

Ouch, that sounds like fun.  Maybe when 2.0 comes out someone will update
the VMS support for GNU C/C++, starting with the latest VAXC header files
(which don't appear to be copyrighted).  All the VAXC-isms in the headers
can be converted to GNU-isms, and that gives you headers that match the
run-time library and the OS in general.  One would probably want to include
Erkki Ruohtula's patch to the preprocessor, which otherwise requires that
include directories be "rooted", and if GNU C could incorporate the C++
concept of anonymous unions it would be helpful in some of the heavily
overlaid VMS structs (VAXC uses "variant_union").

|What is causing me more worry is the definitions of "sdata" and
|"edata".  These are defined with a "globaldef" keyword (and referenced
|with a "globalref" keyword). These are clearly a VAX C extension,
|which apparently allow you to specify what psect a definition ends up
|in. Gcc doesn't recognize these keywords.

Actually what they do is change the linking semantics from the psect-based
system used for conventional C global variables, to the type of linking done
with C functions.  "globaldef" makes the address of a variable visible to the
linker, "globalref" tells the linker to look for the address in some other
module (and "globalvalue" makes a constant value visible by name).  Looking
at it that way, it's pretty simple to fake the "globalref" past GNU C - for
example, to use "cc$rms_rab" from the VAXC library,
#ifdef vaxc
globalref struct RAB cc$rms_rab;
#else
extern CC$RMS_RAB ();	/* For the linker, which is case-insensitive. */
#define cc$rms_rab (*(struct RAB *) CC$RMS_RAB);
#endif

For the "globaldef", I guess the assembler module option would work as well
as anything - something like
.PSECT D$DATA some psect attributes
sdata:: .byte 512
.PSECT __DATA some psect attributes
edata:: .byte 512

|                                           ...  I suppose I could use
|asm's but I don't know if gas understands the psect directive.

Any conventional C global variable is, in effect, a psect directive, which
you can rename using "asm" - e.g.,
(in MAPVMS.C)
char sdata[512] asm ("D$DATA");

(in S-VMS.H)
char sdata[] asm ("D$DATA");

Which has the advantage of no extra modules.  I haven't tried either of these
approaches, mind you, but something along these lines ought to work.

		Donn Cave
		University Computing Services, University of Washington
		donn@cac.washington.edu