dieter@nmtsun.nmt.edu (The Demented Teddy Bear) (05/07/89)
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
eap@bu-cs.BU.EDU (Eric Pearce) (05/11/89)
In article <2587@nmtsun.nmt.edu> you said: >Hi folks. I've been trying valiantly for the last week to get X11R3 >to compile and run under GCC 1.34. (stuff deleted) >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 ;-). >The Purdue 2.1 hacks are >currently installed, but the same thing was happening before. I saw (stuff deleted) >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...). I was able to build the entire core X distribution with gcc-1.34 for the following: (all with the Purdue stuff) Sun4 3.2 Sun4 4.0 Sun3 3.4 Sun3 4.0 Sun386 4.0 This was right out of the box, except for minor changes. I posted the few exceptions a little while ago. The rgb directory needs to be compiled with the Sun compiler for both OS's on the Sun4. I used: gcc -O -fwritable-strings -traditional -finline-functions -fstrength-reduce -DPURDUE You mention that you have an fpa - I assume you mean MC68881 instead of the Sun fpa board or else you would be using "-mfpa". I think gcc uses the 68881 by default anyways. As far as a window system cleaning up after itself, I have noticed some problems with exiting the window system. I usually do this by logging out the root window, most of the time this works fine, but sometimes it starts spitting out "use bye or logout to leave csh", followed by a bunch of "read: operation would block" messages and scary ioctl stuff. The console won't respond to the keyboard after this point. It this something unique to gcc-compiled servers? -e -- ------------------------------------------------------------------------------- Eric Pearce ARPANET eap@bu-it.bu.edu Boston University Information Technology CSNET eap%bu-it@bu-cs 111 Cummington Street JNET jnet%"ep@buenga" Boston MA 02215 UUCP !harvard!bu-cs!bu-it!eap 617-353-2780 voice 617-353-6260 fax BITNET ep@buenga