🚀 go-pugleaf

In article <28649@bu-cs.BU.EDU>, eap@bu-cs (Eric A. Pearce) writes:
>
>
>   I got X11R3 off expo and tried to compile it on a IBM RT running
>   4.3.  This happened during the "make install" phase.  "make world" had worked 
>   without complaint.
>
>   vga % make
>   rm -f vgaData.o
>   /bin/hc -c -O -I. -I../BSDrt -I../ppc -I../../../include -I../../../.././X11
>   -I../common -I../../mfb -DUNIXCPP -DNOSTDHDRS -DHCVERSION=21004 -DBSDrt
>   -DATRIO  vgaData.c
>   E "vgaData.c",L115/C2:  vgaSetColor
>   |    Type "void(unsigned long color,short r,short g,short b)" is not assignment
>   compatible with type "void(*)()".
>   1 user error   No warnings
>   *** Exit 8
>
>   Stop.
> 
>   I built the Xibm server without -DVGA, but it just blanks the screen and dumps
>   core when I try "xinit" (this is on a mpel).
>
>   Any tips would be appreciated.
>
>   -e

First, try using /bin/hc1.4 instead of /bin/hc.  Version 2.1 of the
High-C compiler (i.e. /bin/hc) is so brain dead that even people in
IBM don't use it.  Modify utils/imake.includes/Rt.macros to get this
to happen globally.  Also remember to change HCRevision in the same
file.  One other thing that I have done when porting programs from
other C compilers to High-C is to stuff the following in some include
file or other that is used by everything.  <X11/X.h> comes to mind.

  
/*
 * Totally gross and disgusting hack to get around High-C on an IBM RT
 * treating `char' differently than most other compilers.  Along with
 * assorted other things.
 */

#if	defined(__HIGHC__) && defined(ibm032)
pragma	Off(Char_default_unsigned);
pragma	On(Char_is_rep);
pragma	On(Parm_warnings);
pragma	On(Pointers_compatible);
pragma	On(Pointers_compatible_with_ints);
#endif	/* defined(__HIGHC__) */

This seems to make High-C 1.4 behave like most other C compilers I have
encountered.  Some of the pragmas may not be neccessary but they do not
seem to cause any trouble.
-- 
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            |

In article <28649@bu-cs.BU.EDU> eap@bu-it.bu.edu (Eric A. Pearce) writes:
>
... circumstances described
>   vga % make
>   rm -f vgaData.o
>   /bin/hc -c -O -I. -I../BSDrt -I../ppc -I../../../include -I../../../.././X11
>   -I../common -I../../mfb -DUNIXCPP -DNOSTDHDRS -DHCVERSION=21004 -DBSDrt
>   -DATRIO  vgaData.c
>   E "vgaData.c",L115/C2:  vgaSetColor
>   |    Type "void(unsigned long color,short r,short g,short b)" is not assignment
>   compatible with type "void(*)()".
>   1 user error   No warnings
>   *** Exit 8
>
>   Stop.

Yeah, the problem is that hc is somewhat ansi conformant; you need to change
the line:
	vgaSetColor,		/* void (* setColor)() */

to something like:

      (void (*)()) (vgaSetColor),     /* void (* setColor)() */

OK, I know some of these parenthesis are unnecessary, but I like 'em.
Anyway, my experience is that X11 R3 on the 4.3 RT is too buggy to be
worth the time. Anyway, this should fix that problem.
				Bill Moran

-- 
moran@cs.yale.edu  wlm@ibm.com  uunet!bywater!acheron!archet!wlm

Idealism is fine, but as it approaches reality the cost becomes prohibitive.
				wfb

I've built the X11R3 distribution with the Metaware Compiler distributed
with the December 22, 1988 Release of 4.3 (2.1n, according to cc -v),
with the Purdue 2.1 speedups, and 'official' patches 1-9, with no
problems whatsoever. I've built servers for the megapel, apa16, and
vga/8514 and they all work fine. 

I believe that I made some changes to get it to compile under the
previous release, but I'm not sure. I think I can hunt down the diff
file(s) if you want.

							Adam

-----------------------------------------------------------------------------
Internet: feigin@tcgould.tn.cornell.edu		Adam Feigin
Bitnet: feigin@crnlthry				Workstation Consultant
UUCP: {backbones}!cornell!batcomputer!feigin	Cornell National Supercomputer