Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  X server prob on Sun3 sunos 4.1.1
Message-ID: <9105062237.AA14906@lightning.McRCIM.McGill.EDU>
Date: 6 May 91 22:37:53 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 46

>>> Getting interface configuration: Operation not supported on socket

>>> SunOpenFrameBuffer: inappropriate ioctl for device

>>> Fatal server bug!
>>> no screens found

>> This looks a great deal like the gcc fixincludes problem.

> I don't think this is a fixincludes problem.

> I compiled X11R4 upto patch level 14 (I think) on SunOS 4.0.3c (on
> Sun 3/60) with gcc-1.37.1 (did run fixincludes).  X ran fine.

> I recently compiled X11R4 upto patch level 18 on SunOS 4.1.1 (on Sun
> 3/60) with gcc-1.39 (did run fixincludes).  X did *not* run and gave
> the errors mentioned above.  In fact, I got suspicious when constype
> (mit/server/ddx/sun/constype) didn't give the correct answer (it gave
> me "tty" instead of "gx").  So I compiled constype with cc and got
> the correct response.  Then I compiled it with first doing a "ln -s
> /lib/cpp /usr/local/lib/gcc-cpp".  Presto.  It worked.  Something
> seems to be wrong with either gcc-1.39's cpp or with fixincludes,  I
> would guess.

Yeah, it still looks to me like the fixincludes problem.  The
difference between gcc's cpp and /lib/cpp is that gcc's is an ANSI cpp
and doesn't substitute macro arguments within character constants in
the replacement text, whereas /lib/cpp is a Reiser-style cpp and does.
This causes (almost[%]) all ioctls to compile to wrong value, so of
course they all fail.

As for "did run fixincludes", well, I think it probably didn't work.
Try the short test from question 80 of the recently-posted FAQ.
Perhaps fixincludes doesn't deal with 4.1.1 correctly, perhaps 1.39's
fixincludes is broken, perhaps something else is wrong.  But if you
can't get the short test to work, there's really no hope of getting X
to behave.

[%] "almost" all because an ioctl whose subsystem-selection character
    matches the macro argument name (usually x) will come out with the
    correct value in spite of ANSI-vs-Reiser semantics.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu