Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!nmtsun!dieter
From: dieter@nmtsun.nmt.edu (The Demented Teddy Bear)
Newsgroups: comp.windows.x
Subject: GCC, X11R3, Purdue, and windows from Hell
Message-ID: <2587@nmtsun.nmt.edu>
Date: 7 May 89 09:50:00 GMT
Reply-To: dieter@nmtsun.nmt.edu (The Demented Teddy Bear)
Organization: New Mexico Tech, Socorro NM
Lines: 50


Hi folks.  I've been trying valiantly for the last week to get X11R3
to compile and run under GCC 1.34.  Rather, I can get it to compile,
but when I start it up (using the sample .xinitrc), interesting things
happen:

	o The standard grey background and X mouse cursor appear.
	o The clock square appears in a kind of forest green colour (you
	  can't see anything on it) and then it disappears.
	o The two default xterms start up, but they are also forest green
	  with no apparent text in them.  However, you can type at them
	  and have things happen.

The hardware is a Sun 3/260 (SunOS 4.0.1) with an FPA and a GP.
Compile-time flags were ``-traditional -finline-functions -m68881''.
Initially, I only had -traditional; with the other flags it acts the
same, but does it faster ;-).  Run-time options don't seem to make
much difference, I've tried ``xinit'', ``xinit -- -dev /dev/cgtwo0'',
and ``startx'' with identical results.  The Purdue 2.1 hacks are
currently installed, but the same thing was happening before.  I saw
something about a bug fix and had hopes.  Oh well.

Now, if I cheat and start everything up using what was generated via
the Sun C compiler and then start using the GCC executables [*] after
initial startup, an interesting clue appears.  If I run ``ico'', it'll
fire up a window, and then die with a bus error in sincos ().  Another
interesting thing is that if I exit the main shell and leave the other
sitting there, it becomes quite readable when X exits (this tickles one
of my pet peeves, though.  A windowing system should clean the screen
up after it when it exits, not just let the invoker deal with it.  A
minor quibble in this case...).

[*] X is living in its own directory tree, with soft-links in all the
right places.  It's easy enough to rename the root of that tree to
something else and rename the gcc-generated tree to the original.
Sleazy, but it makes testing a little easier.

So, does anyone have any ideas about why I'd be getting opaque forest
green windows instead nice, clear black & white windows?  Why does the
clock die?  Why does ico core dump?  Why is the Moon's cheese green?

Please e-mail responses, and I will summarize if needed.  If, as I suspect,
this has been hashed to death a month and a half ago, just kindly mention
it.  Thank you.

Dieter Muller
-- 
Welcome to the island.  You are number six.
dieter%nmt@relay.cs.net
dieter@jupiter.nmt.edu