bzs@BU-CS.BU.EDU (Barry Shein) (10/31/87)
These are my notes while bringing up X11 on an Encore/320 (APC, 3.0)
machine.
Since I wrote this something else came up:
For some reason a BUFSIZE of 2048 is too big for the writev in _XSend
(in XlibInt.c). Change it to 1024 (I ifdef'd around it using ns32000)
and rebuild libX.a and everything that refers to it (that is, almost
everything.)
A symptom of this problem is that xterm's will mysteriously exit with
status 84 (which, if you trace back thru xterm, is an XioError and
errno is 40 or "EMSGBIG" or something like that.)
Anyhow, 1024 seems to work, you could try 1536 or some such if
you're ambitious.
The more timid might consider waiting a few days for more bug
fixes like this. The more bold might help :-)
-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.jb@cs.brown.EDU (Jim Bloom) (11/01/87)
I haven't tried to put up X11 yet on the multimax. You will probably hit the same problems I had with X10. Bcopy() doesn't handle overlapping strings properly. This shows up while backwards scrolling and inserting in vi. Bzero cannot zero 1-3 bytes correctly. 4 bytes are zeroed in these cases. I can post fixes to the bcopy and bzero problems if people want. I have had problems with select as well. Select when given a NULL pointer to the timeout would return instantly with no descriptors ready and a return value of zero. Xterm core dumped almost immediately. This problem may have been fixed in later versions. Xload needs a bit of work since the load average is computed differently. Nlist() is not a valid operation and avenrun does not contain the load. As for the problems with include nesting, there is a compiler switch which may be used to run cpp external to the normal C compiler first. (I seem to remember this being correct.) This might be an easier way to do things. Jim
george@fubar.cis.ohio-state.EDU (George Jones) (11/01/87)
>Xload needs a bit of work since the load average is computed differently. >Nlist() is not a valid operation and avenrun does not contain the load. I have a quick and dirty xload (X10) that picks up the load from the stdout of "uptime" if anyone is interested. ----------------------------------------------------------------------- George M. Jones (soon) george@fubar.cis.ohio-state.edu Computer Science Department george@ohio-state.arpa The Ohio State University george@ohio-state.csnet +1 (614) 292-7325 ...cbosgd!osu-cis!george