oneill@bass.bu.edu (Brian V O'Neill) (10/05/90)
I have been trying to compile X11R4 on a DECstation 3100 and a 5000 under Ultrix 4.0. I've almost completed it, but now I get an error when compiling main.c in clients/xterm: cc -c -O -Wf,-XNh2000 -Olimit 2000 -I../../. -DUTMP main.c ccom: Error: main.c, line 823: illegal lhs of assignment operator ((int)(((&_iob[2]))->_file)) = i; Any quick ideas? Thanx... -- ============================================================================ Brian O'Neill - Local Internet Access Account Internet: oneill@bu-pub.bu.edu UUCP : ...!bu.edu!bu-pub!oneill
klee@wsl.dec.com (Ken Lee) (10/06/90)
In article <65635@bu.edu.bu.edu>, oneill@bass.bu.edu (Brian V O'Neill) writes: |> I have been trying to compile X11R4 on a DECstation 3100 and a 5000 under |> Ultrix 4.0. I've almost completed it, but now I get an error when compiling |> main.c in clients/xterm: |> |> cc -c -O -Wf,-XNh2000 -Olimit 2000 -I../../. -DUTMP main.c |> ccom: Error: main.c, line 823: illegal lhs of assignment operator |> ((int)(((&_iob[2]))->_file)) = i; There are a couple of places where xterm says (for various instances of foo): fileno(stderr) = foo You should change these to: stderr->_file = foo -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
mouse@LARRY.MCRCIM.MCGILL.EDU (10/06/90)
> I have been trying to compile X11R4 on a DECstation 3100 and a 5000 > under Ultrix 4.0. I've almost completed it, but now I get an error > when compiling main.c in clients/xterm: > cc -c -O -Wf,-XNh2000 -Olimit 2000 -I../../. -DUTMP main.c > ccom: Error: main.c, line 823: illegal lhs of assignment operator > ((int)(((&_iob[2]))->_file)) = i; > Any quick ideas? xterm contains some nonportable code. As written, it assumes that stdio's fileno() function is actually a macro that returns an lvalue. This has traditionally been true but is not a portable assumption; DEC's stdio has a fileno() of which this is not true. (I understand this is required by some standard or other.) The quick fix is to change all assignments of the form fileno(foo) = bar; (for any particular foo and bar) to foo->_file = bar; This makes a different nonportable assumption about the stdio internals, which I believe happens to be true under Ultrix 4.0. As I read the code, it wouldn't be difficult to change it to remove these gross assumptions about stdio internals by using dup2(). (What is really needed is an fdreopen() function which combines fdopen() and freopen(), but that's neither here nor there.) I am not including a patch to do this because I am not sure I understand how the code in main.c interacts with the code in misc.c; my first impression is that the latter is intended to undo the damage done by the former. Sigh. Someone should go through and fix this. xterm shouldn't be using stderr for its debugging output; it should have a distinct FILE * which it then prints to using something like dprintf(va_alist) va_dcl { va_list ap; char *fmt; if (debugf) { va_start(ap); fmt = va_arg(ap,char *); vfprintf(debugf,fmt,ap); va_end(ap); } } But no, that's too sensible[%]. (Actually it should be conditional on __STDC__, to use the <stdarg.h> mechanism if available, but I don't want to bloat this note excessively.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu [%] If this sounds cynical and slightly bitter, that's not surprising. I feel cynical and slightly bitter about it.