Xref: utzoo comp.unix.sysv386:3959 comp.windows.x:31454
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!usc!apple!agate!shelby!portia.stanford.edu!elaine30.stanford.edu!fangchin
From: fangchin@elaine30.stanford.edu (Chin Fang)
Newsgroups: comp.unix.sysv386,comp.windows.x
Subject: Re: Can't run clients under (Roell's) X11R4 for ISC
Keywords: X11R4, comp.windows.x
Message-ID: <1991Jan12.061432.27366@portia.Stanford.EDU>
Date: 12 Jan 91 06:14:32 GMT
References: <130@chansw.UUCP> <278E6093.15392@orion.oac.uci.edu>
Sender: news@portia.Stanford.EDU
Organization: Stanford University, California, USA
Lines: 26

In article <278E6093.15392@orion.oac.uci.edu> drector@orion.oac.uci.edu (David Rector) writes:
>In <130@chansw.UUCP> chan@chansw.UUCP (Jerry H. Chan) writes:
>
>>Anybody experience problems running Roell's X11R4 binary distribution (local
>>connections) with the following clients?
>
>>* No clients from ISC's X11R3 distribution (R1.1)
>>  (Same X11R3 clients work with NCD X-terminal running prom-based server)
>>* X11R4 xclock -- quits by itself; oclock works properly
>
According to the latest FAQ of comp.windows.x, the xclock has bug which
prevents it from function properly in X11R4 environment (but you can run
it in X11R3).  It has been fixed and a new src has been posted laterly.
Check that FAQ for more details. 

I found out this in the hard way.  I tried to use Thomas Roell's X386  
ported to ESIX by Mike Knister of U.Michigan.  When I started xclock,
it core-dumped right away.  Later when I read the FAQ for X, I learned
the existance of the bug. 

Regards,

Chin Fang
Mechanical Engineering Department
Stanford University
fangchin@portia.stanford.edu