rpd@CS.CMU.EDU (Richard Draves) (12/06/88)
After much time with adb, I managed to get an R3 server working on a Megapel
display. (Why doesn't IBM supply source for the ppc functions???) I am
building my server with hc1.4u -g. The server core-dumped, typically in some mi
function, when trying to tile the root window with the initial background. The
function mpelTile calls ppcTileRect, which called through a null pointer. Turns
out mpelInitScreen wasn't initializing one of the fields in its device-private
structure. Adding a line like
devPriv->replicateArea = ppcReplicateArea;
fixed the problem.
With that fixed, I saw occasional divide-by-zero faults in mfbPadPixmap. It
seems the mysterious ppcPolyGlyphBlt is calling miPolyGlyphBlt with some 0x0
glyphs. That is, gWidth and gHeight are 0 when it calls miPutImage. This
eventually leads to mfbPadPixmap and mfbUnnaturalStippleFS trying to divide by
zero, because the width of a pixmap is zero.
Is this a bug in miPolyGlyphBlt or ppcPolyGlyphBlt? Right now, I've modified
miPolyGlyphBlt to skip over glyphs whose height or width is zero.
Richtomw@grey.ucsb.edu (Tom Weinstein) (12/07/88)
> (Why doesn't IBM supply source for the ppc functions???)
They don't include the source because all of that stuff is top secret. It's
the stuff that makes the RT server run so damned fast, and allows them to
port it to a new server very quickly.
Tom Weinstein
* signature under construction *rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/11/88)
It seems the mysterious ppcPolyGlyphBlt is calling miPolyGlyphBlt with some 0x0 glyphs. That is, gWidth and gHeight are 0 when it calls miPutImage. Is this a bug in miPolyGlyphBlt or ppcPolyGlyphBlt? Strictly speaking it's probably a bug in miPutImage, but Right now, I've modified miPolyGlyphBlt to skip over glyphs whose height or width is zero. That's the reasonable solution anyway.
ehrlich@shire.cs.psu.edu (05/03/89)
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 <ehrlich@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 <ehrlich@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 |jik@ATHENA.MIT.EDU (Jonathan I. Kamens) (05/04/89)
Date: 3 May 89 13:02:51 GMT
From: shire.cs.psu.edu!ehrlich@psuvax1.cs.psu.edu
Organization: Department of Computer Science, Penn State University
Sender: xpert-request@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
jik@Athena.MIT.EDU Cambridge, MA 02139-4318
Office: 617-253-4261 Home: 617-225-8218ehrlich@SHIRE.CS.PSU.EDU (Daniel R. Ehrlich) (05/04/89)
>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
swick@ATHENA.MIT.EDU (Ralph R. Swick) (05/04/89)
Date: Thu, 4 May 89 01:15:34 EDT
From: Jonathan I. Kamens <jik@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
+ #endifehrlich@SHIRE.CS.PSU.EDU ("Daniel R. Ehrlich") (05/04/89)
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
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (05/06/89)
> 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: kit@expo.lcs.mit.edu
Phone: (617) 253 - 9608
Address: MIT - Room NE43-213