[comp.windows.x] Building X11 on the Encore MultiMax

bzs@BU-CS.BU.EDU (Barry Shein) (10/31/87)

The following were my notes on building X11 (no server) on the Encore
Multimax, specifically a 320 (APC/332) running Umax/3.0.

The problems were various and curious, none terribly severe (so far)
but developers from the vendor and X might want to glance over the
list to see if there's anything they wished they had done slightly
differently.

	-Barry Shein, Boston University

1. Go through and disable the server build in the makefiles, at least
in the top and extensions makefile. You'll only need server/include
in that directory (all the .h files.)

2. Create a dummy file /usr/include/machine/machparam.h, several
makefiles refer to these and it's easier than rebuilding all the
make depends or fixing all the makefiles manually.

3. The file lib/XlibInt.c has a switch around line 302 which has no
braces (the innermost nested switch.) This is technically legal (I
think) but the Encore C compiler gripes about it so add the braces
(this was reported to xbugs and although they doubt the Green Hills C
compiler's opinion they agree that there's no harm in putting the
braces in as a "fix" so a later release or one with all patches
applied may cease to have this problem.)

4. Unfortunately, on the Encore, <param.h> pulls in <sys/types.h>.
Xlib.h also pulls in <sys/types.h> so you get redefinition errors.
My fix was to bracket the whole sys/types.h file with:

#ifndef _SYS_TYPES_H_
#define _SYS_TYPES_H_
...everything...
#endif

so that re-includes are now harmless.

5. The file clients/gnuplot/plot.h has a 'typedef int BOOLEAN' which
clashes with the one in <sys/types.h>. Ugh. My cheap shot was to
follow my own example above and surround it with:

#ifndef _SYS_TYPES_H_
typedef int BOOLEAN;
#endif

I know, I know...

6. There is no lgamma() in the Encore math library so you have to
remove the -DGAMMA from the Makefile (obviously this lack is not
unique to the Encore.)

7. One of those CASE NOT AT TOP LEVEL error messages is generated when
compiling client/uwm/Menu.c. Green Hills C is picky about something there,
we've run into it before (perhaps the case label is nested into an
if() statement or something.) My fix was to remove uwm from the Makefile
as I have no reason to run it on the Encore anyhow, I assume users run
their window managers on their servers. If you don't agree you'll have
to fix that file.

8. In client/xmh/command.c you need to define the type fd_set after:

#ifndef FD_SET
typedef struct fd_set { int fds_bits[1]; } fd_set;
	....

9. Uh oh, trouble in paradise. The two files VTparse.h and Tekparse.h
nest their #define's too deeply for Green Hill's pre-processor in
clients/xterm. I considered several possibilities (including going
for GNU's cpp) but decided I would be doing the world a service if
I solved this (even if only this one time) with something quick and
generic.

What I did was create an awk script which turned the .h files into
an m4 file which, when run thru m4, produced a resolved .h file.

	1. cp VTparse.h VTparse.h.orig
	   cp Tekparse.h Tekparse.h.orig

	2. Copy the following small awk program to a file XXparse.awk

--------------------from here--------------------
{
	if($1 == "#define") {
		if(substr($3,0,1) == "0") {
			printf("define(%s,%s)\n",$2,$3)
		}
		else {
			split($3,val,"+")
			printf "define(%s,incr%s))\n",$2,val[1]
		}
		printf "`#define %s' %s\n",$2,$2
	}
	else print $0
}
--------------------to here--------------------

	3. Copy the following small shell script to some file (XXparse.sh)

--------------------from here--------------------
#!/bin/sh
for in in VTparse.h.orig Tekparse.h.orig
do
	out=`basename $in .orig`
	if [ ! -f $in ]; then
		echo you forgot to copy $out to $in
	else
		awk -f XXparse.awk $in | m4 > $out
	fi
done
--------------------to here--------------------

	4. Run the shell script and 'make xterm'.

Xterm then works fine as far as I can tell (which is probably what
you're mostly after anyhow, to start.)

You might want to double check the results of the above (in the .h
files) and be very careful if you apply any fixes later as this
solution is not at all robust, but it got me thru the night.

10. Don't use parallelism (setenv PARALLEL N, N>1) when building
util/rgb, it seems to confuse the dbm build (bad block: core dumped.)
Otherwise seems fine.

11. That's it, now onward to see if it all really works.