X11 R3 on RTs (again)

[ehr...@shire.cs.psu.edu]

After obtaining the `new' X11 R3 server code from expo I tried to make
World only to discover that the MetaWare High-C compiler version 1.4r
gets extremely upset with the XtOffset macro defined in
X11/Instrinsic.h and complains with errors like the following every
time the macro is used:

E "Composite.c",L36/C16:
| Must be a compile- or load-time computable expression.
Object module not generated.

The PCC compiler doesn't seem to think that what XtOffset does is a
problem, but I would prefer not to compile all of X11R3 with PCC.
Also I do not want to have to figure out every module that uses the
XtOffset macro and change the Imakefiles to use PCC on them.

Has anyone else come across this? Does anyone have a suggestion for a
solution? I was about to write an XtOffset function to replace the
macro but would like to hear other suggestions before I proceed.
Thanks in advance.
--
Dan Ehrlich <ehr...@shire.cs.psu.edu> | Disclaimer: The opinions expressed are
The Pennsylvania State University | my own, and should not be attributed
Department of Computer Science | to anyone else, living or dead.
University Park, PA 16802 |

Dan Ehrlich <ehr...@shire.cs.psu.edu> | Disclaimer: The opinions expressed are
The Pennsylvania State University | my own, and should not be attributed
Department of Computer Science | to anyone else, living or dead.
University Park, PA 16802 |

[Jonathan I. Kamens]

Date: 3 May 89 13:02:51 GMT
From: shire.cs.psu.edu!ehr...@psuvax1.cs.psu.edu
Organization: Department of Computer Science, Penn State University
Sender: xpert-...@expo.lcs.mit.edu

After obtaining the `new' X11 R3 server code from expo I tried to make
World only to discover that the MetaWare High-C compiler version 1.4r
gets extremely upset with the XtOffset macro defined in
X11/Instrinsic.h and complains with errors like the following every
time the macro is used:

E "Composite.c",L36/C16:
| Must be a compile- or load-time computable expression.
Object module not generated.

Yeah, we had this problem in a major way here at Athena. The other
problem is that developers of Xt applications that use XtOffset lose
in a major way since our default compiler is hc and we had to give
specific instructions to tell people to use pcc.

There are two possible solutions to the problem:

1. Get the new hc (hc 2.1o, I think, is the most recent version), in
which this problem is fixed.

2. Augment your Imakefile rules for RT's so that each directory gets
compiled first with "make -k CC=hc" and then again with "make -k
CC=pcc." This way, any files that didn't build properly the first
time because of the XtOffset will build properly the second time
through.

Jonathan Kamens USnail:
MIT Project Athena 410 Memorial Drive, No. 223F
j...@Athena.MIT.EDU Cambridge, MA 02139-4318
Office: 617-253-4261 Home: 617-225-8218

[Daniel R. Ehrlich]

>There are two possible solutions to the problem:
>
>1. Get the new hc (hc 2.1o, I think, is the most recent version), in
> which this problem i>s fixed.

Yesterday I pulled hc 2.1n off of the December 1988 release tapes (we are
still running the September 1988 code) and started a make of World again.
Before doing this I tried compiling some of the routines that hc 2.1d was
complaining about without error, so hopefully the build completed over night
and I have X11R3 ready to be installed.

Thanks for the help.

--Dan Ehrlich

[Ralph R. Swick]

Date: Thu, 4 May 89 01:15:34 EDT
From: Jonathan I. Kamens <j...@ATHENA.MIT.EDU>

There are two possible solutions to the problem:

1. Get the new hc

2. Augment your Imakefile rules for RT's

There is also a BandAidCompiler (see util/imake.includes/Rt.BAC)
hack that is intended to be defined in Rt.macros if you're using
a broken hc:

+ /*
+ * hc revision 1.4r won't compile parts of Xt and some clients.
+ */
+ #if HCRevision == 14018
+ #define BandAidCompiler "Rt.BAC"
+ #undef MacroFile
+ #define MacroFile Rt.macros $(IRULESRC)/Rt.BAC
+ #endif

[Daniel R. Ehrlich]

Just tried doing an `make -k install.man' and noticed that the man page names
were not being expanded and the section 3 stuff is being installed with an
extension of .3X11 which man on the RT doesn't grok. Any suggestions as to
how one could fix this? Thanks in advance.

--Dan

[Chris D. Peterson]

> Any suggestions as to how one could fix this? Thanks in advance.

Here is a cshell script that will do the trick.

--------------
#! /bin/csh

foreach file (*.3X11)
mv $file $file:r.3
end
--------------

Chris D. Peterson
MIT X Consortium

Net: k...@expo.lcs.mit.edu
Phone: (617) 253 - 9608
Address: MIT - Room NE43-213