spaf@cs.purdue.EDU (Gene Spafford) (03/09/88)
I got the distribution from decwrl the day it was announced. I had no
evidence of bitrot or other problems, as some have posters have
complained. Probably the fact we have a direct Cypress link to decwrl
from Purdue helped (yea, Cypress!).
Compiling and installing produced some interesting bugs, some reported
officially, and some not (I'm not doing a Beta test or product
evaluation, so I'm not going to spend a lot of time filling out bug
reports, especially after the response I got to my first bug report --
see below). We've got it in use on a number of our Suns here and it
seems to work okay.
All the following comments concern compiling and using X for Sun 3
machines under SunOS 3.4:
1) I tried adding another compiler switch to the imake templates, to
be included with the CFLAGS in target Makefiles. I wanted to add the
"-pipe" and "-fswitch" compiler flags. Trying a "make depend"
resulted in disaster as the flags got supplied to "makedepend" and it
barfed when it tried to parse them.
So much for augmenting the default compiler flags.
2) in server/ddx/sun, 3 of the subroutines fail to compile because
"errno" isn't defined. I submitted this as an official bug report.
The response was that it worked fine there, so it must be my version of
SunOS that didn't have a declaration in errno.h. An exchange followed
about the version of the SunOS we're running (we're running SunOS 3.4
right off the tape we were sent), and I was left with the impression
that nothing would be done, even though a fix could be made that would
be transparent to anyone's version of SunOS.
Fix: add "extern int errno" to sun.h in that directory.
Additional result: I'm less likely to fill in official bug reports.
3) If you set the define to YES for building and installing the
contributed software, a "make World" dies horribly in the contributed
software directory. In fact, it dies BEFORE it has finished installing
all of the core distribution. Setting the flag to NO seems to make no
difference -- if you type "make install" it attempts to install the
contributed software as well, resulting in all sorts of botches &
problems.
4) xinit hangs when invoked from ksh or tcsh; this has been reported
in a previous article to this group. According to my mail, this
problem has been reported a couple of times to the X group
ever since version 1 was released.
Fix: posted in a previous article.
Additional result: I'm even less likely to spend time filling in
official bug reports.
5) If you kill the parent of a backgrounded xinit, SunOS sometimes
hangs and has to be manually rebooted. This is probably a bug with
SunOS and not X, but it *is* a problem. I can't reliably recreate
it other than to make this observation, and I'm not going to try
to track it down further -- so far, I haven't trashed my disk any
of the 3 times this has happened to me, but I'm not pressing my luck.
6) xmh comes up with the window with all the little boxes present,
but there is no text in any of them. Mouse clicks in the boxes
produces no activity. It just sits there -- anybody know why?
(Yes, we have all the mh commands installed locally).
7) xman dumps core with floating exceptions if the MANPATH variable
doesn't name a directory with man? subdirectories; we keep all
our peripheral man directories with just the cat? directories to
save space, so using xman isn't possible.
8) There is no clear documentation anywhere on how to set up
.Xdefaults, or *when* to put resources in xrdb or use the
XENVIRONMENT variable. Neither is there any clear information
immediately accessible (i.e., "man" pages) on the exact syntax and
semantics of those resources. I just want to use the system, and I
don't think I should have to wade through hundreds of pages of library
specification or read the source code to use a standard feature. Jim
Fulton replied to my earlier posting on this subject, but I still think
there should be a man page on resources, including examples, lists of
built-in defaults, and some indication of how we might use the
incredible flexibility that the mechanism seems to provide.
9) What happened to title bars on xterms?
I hope the wrong idea isn't conveyed by my complaints. The package
dropped right into place and came up with almost no problems; I'm
pleased with the way it all configured and works. However, the problems
that did occur expose some flaws in the Beta test procedures used with
the release (doesn't *anyone* in the X Consortium use ksh? xmh? use
other than default compiler switches?).
--
Gene Spafford
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spafekrell@hector.UUCP (Eduardo Krell) (03/10/88)
In article <3466@medusa.cs.purdue.edu> spaf@cs.purdue.EDU (Gene Spafford) writes: >2) in server/ddx/sun, 3 of the subroutines fail to compile because >"errno" isn't defined. I submitted this as an official bug report. >The response was that it worked fine there, so it must be my version of >SunOS that didn't have a declaration in errno.h. An exchange followed >about the version of the SunOS we're running (we're running SunOS 3.4 >right off the tape we were sent), and I was left with the impression >that nothing would be done, even though a fix could be made that would >be transparent to anyone's version of SunOS. I compiled X.V11R2 on a SUN 3/60 running vanilla SunOS 3.4 right off the tape we were sent and I didn't have any problem compiling the whole thing, so it seems like you either don't have a vanilla 3.4 distribution or something else in your environment is screwed up. >4) xinit hangs when invoked from ksh or tcsh; this has been reported >in a previous article to this group. According to my mail, this >problem has been reported a couple of times to the X group >ever since version 1 was released. Again, I run ksh as my login shell and xinit works fine. The only problem I have is that when I exit X, I get logged out, but I don't know if this is related to ksh or not. BTW, I'm running ksh version 06/03/86a. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com