Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!munnari.oz.au!csc!csc3!arp!gustav
From: gustav@arp.anu.oz.au (Zdzislaw Meglicki)
Newsgroups: comp.windows.x
Subject: X11R4 on the Sequent S27
Message-ID: <1990Feb1.020727.26258@arp.anu.oz.au>
Date: 1 Feb 90 02:07:27 GMT
Organization: Automated Reasoning Project, ANU, Australia
Lines: 62

I have been trying to install MIT's X11R4 on the Sequent Symmetry
S27 running DYNIX(R) V3.0.12 NFS. I have defined sequent.cf as follows:

	#define OSName			4.2bsd
	#define OSMajorVersion		4
	#define OSMinorVersion		2
	#define HasSaberC		YES /* not sure about this         */
					    /* but most of other .cf files */
					    /* had it set to YES           */
	#define HasVoidSignalReturn	NO
	#define SystemV			NO
	#define HasBsearch		NO
	#define HasInputExtension	NO /* cc crashed while making      */
					   /* xinput in the extensions     */
	#define HasSharedLibraries	NO
	#define BuildServer		NO /* no server installed because  */
					   /* X accessed only from Sun     */
					   /* workstations via network     */
	#define BuildExamples           NO
	#define ExtraLibraries		-lseq

On top of that appropriate sequent entries were made in Imake.tmpl and
imakemdep.h. site.def asked said:

	#define HasLargeTmp            YES
	#define InstallOldHeaderFiles  YES
	#define HasXwWidgets           YES
	#define HasXcuWidgets          YES

apart from all the standard things which you can find in the vanilla
site.def.

I have defined in the sequent.cf "HasInputExtension NO", because the
compiler crashed while trying to make xinput in extensions. 

The compilation then went smoothly with the exception of xdm, which
requires that cript and setkey are available on the system which is
not the case for the S27 running DYNIX.

After installation I tested some of the programs and I have found that
for instance xterm, and xload worked without problems. However xedit
had problems. If called with a filename on the command line:

	xedit myfile

it would crash immediately on clicking a mouse button in the main input
window. If called simply by

	xedit

it would crash sooner or later too, but only after a while and not always
predictably. Running dbx on the core dump showed that alloca, and malloc
were the last calls - these in turn originated from Xalloc and Xtalloc.

Now the question is: what went wrong? Xperienced Sequent hackers, please,
reply to the net and/or to me:

	gustav@arp.anu.oz.au

	Gustav Meglicki, Automated Reasoning Project,
	The Australian National University,
	GPO Box 4, Canberra, ACT 2601, Australia