aslam@uiucdcsm.cs.uiuc.edu (03/09/88)
---------- "Building X11R2 on the Encore MultiMax" ---------- >I thought I pass this on to xpert readers. I've got X11 Release 2 Core >running on the ENcore Multimax. Barry Shein (bzs@BU-CS.BU.EDU) had posted >notes regarding X11 Release 1 on the Encore. I have merged my notes with >his notes. My notes are preceded by the `>' symbol. I haven't build the >contributed software yet. The following were my notes on building X11R1 (no server) on the Encore Multimax, specifically a 320 (APC/332) running Umax/3.0. -Barry Shein, Boston University >I am running Umax 4.2 (R3_1.0). > -Sohail Aslam, Univ. of Illinois 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. >things have shaped up now. 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.) >You must do this. I removed the server directory in the top level >Imakefile because `make World' regenerates the top level Makefile. >If you don't do this and no server is specified, `make depend' will >bomb with shell complaining about unexpected `;' (the for loop is >incomplete: `for i in ;' The server name appears after `in' when >building a server.) 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. > I left this in /usr/include/machine. 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.) >Fixed in new release. 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. >I went ahead and did this. I didn't check whether it was still necessary. 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 haven't made the contributed stuff which is where gnuplot now lives. 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.) >Haven't checked this. 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. >Didn't see this error in R2 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; .... >Don't need to. Fixed in new release. 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. >Didn't happen with R2. 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. >I didn't use the PARALLEL directive. 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. >Haven't run into this problem yet. ------------------------------------------------------------------------- > >Here are some other notes from building X11R2 core on the Encore. I haven't >tried building the contributed sotfware. > >1. The ar clq line in lib/X while building libX.a is too long. Shell bombs >with memory fault. I had to ranlib by hand. Make continued though. > >2. While compiling fonts, the compiler complained that the bit ordering >was not specified. It used MSBfirst by default. Encore is Vaxlike. I wonder >if it should be LSBfirst. Xterm worked fine with the fonts that were built. > >3. In clients/x10tox11/X10/Xinit.h compiler complains about the type `ushort'. >Under SunOS 3.5, ushort is defined to be `unsigned short in <sys/types.h>.' I >defined it in Xint.h on the Encore because I don't think anyone else uses it. > >Sohail Aslam >Department of Computer Science >University of Illinois >arpa aslam@a.cs.uiuc.edu >csnet aslam@uiuc.csnet >usenet {ihnp4,seismo}!uiucdcs!aslam >