alfred@unisql.UUCP (Alfred Correira) (12/14/90)
Background: I sent out the following plea several days ago on another forum; it
concerned a problem I was having with a freshly built release of X11R4:
===============================================================================
My X11 build/install proceeded without problem. The problems came about when
I tried to test the installation; I can invoke xinit from the shell and cause
certain windows to appear provided they are the results of xterm, xload,
xclock, for example, calls. As soon as I try to start twm, or invoke xset or
xsetroot (for example), I bomb out with a fatal error. This happens whether I
put the calls into my .xinitrc, or have no .xinitrc at all and manually type
the commands in when I get the default xterm you get when you have no .xinitrc.
I get the errors whether or not I have a .twmrc. As soon as either mechanism
(invoked via .xinitrc or manually from an xterm window) gets to the twm (for
example), I get s.t. along the lines of:
XIO fatal IO error 32 (Broken pipe) on X server "unix:0.0"
...
xterm: fatal IO error 32 or KillClient on X server "unix:0.0"
xinit: connection to X server lost.
and I'm back at the shell from which I invoked xinit.
I compiled X11 using gcc 1.37.1. I installed all 18 patches I found at expo.
I am running SunOS 4.1 on Sun 1+s and SLCs.
===============================================================================
Well, the problem came down to gcc, in two stages. I was actually barfing
because the Xsun server was getting a segmentation violation trying to read the
rgb.dir file in /usr/lib/X11 and that file was empty. It turned out to be
empty because I failed to notice that the build segment for rgb.{dir,pag} from
rgb.txt failed. It failed because gcc did not correctly compile the rgb.c file
that produces the former from the latter (or, rather, it compiles the program
but it blows up during the processing of the rgb.txt input file). When I
recompiled this little piece again using cc, I was able to successfully produce
rgb.{dir,pag} from rgb.txt (and showrgb did the ``right thing'' when invoked).
I presume this problem is recent (gcc 1.37.1 being a pretty new release),
because the X11R4 build instructions suggest using gcc for the build (except
for the portions that require position independent code be generated), and the
X11 folk could hardly have failed to notice this behavior with whatever version
of gcc they were using ;-)
This is stage 1, and not the main purpose of this message.
When I again tried to start up Xsun, I again failed when I started up twm, and
in the same dbm_fetch call (called from OsLookupColor)! However, upon closer
examination, the problem was not in the same place: instead of barfing on the
empty rgb.dir file, it was barfing somewhere around the return (I think). I
recompiled Xsun with cc, and the problem went away (i.e., twm ran with Xsun
just fine). It would appear, given that the cc-compiled code works and the
gcc-compiled code doesn't, that the problem lies with the mix of gcc-compiled
Xsun code and cc-compiled ndbm code. The ndbm code is returning a struct value
(of type datum) -- _not_ a pointer to same; could, perhaps, gcc be messing up
how it handles struct return values under the influence of the
-fpcc-struct-return flag (which was enabled for all the gcc compilations during
the X11 make World)? {Note: We tried creating some small code experiments with
struct returns in mixtures of cc-compiled gcc-compiled code but could not
isolate a case with behavior similar to what we were seeing (so maybe we're
barking up the wrong tree?)}
Anyway, at that point I threw in the towel and just recompiled everything
with cc instead of gcc. I now have a functioning X11 environment.
And, NOW FINALLY, for the questions:
(1) How did I come to be in this state? That is, why did the combination of
factors here (X11R4 thru fix-18, gcc 1.37.1, SunOS 4.1) cause a problem that
the few respondents to my earlier plea hadn't themselves encountered and which,
apparently, the X11 folk hadn't either (or did I miss some previous posting
about this very thing)? (This is X windows question)
(2) Does anyone have a line on what is the True Source of the problem? Does it
have something to do with struct return or is it likely to be something else
(I'm out of my element looking at disassembled code)? (This is the gcc
question)
--
alfred
Internet: execu!sequoia!unisql!alfred@cs.utexas.edu
UUCP: {uunet, cs.utexas.edu!execu}!sequoia!unisql!alfred
The government I live under has been my enemy all my active life.
When it has not been engaged in silencing me it has been engaged in
robbing me. So far as I can recall I have never had any contact with
it that was not an outrage on my dignity and an attack on my security.
-- from The Diary of H. L. Mencken