dmocsny@uceng.UC.EDU (daniel mocsny) (03/14/90)
Hello. I thought I would try installing rn under Interactive 2.0.2. I ran into a few hitches. The first was minor, a redeclaration of sprintf(). The second (so far) has me somewhat stumped. I get the cc error: "intrp.c" line 538, CBREAK undefined. Grep'ing the sources shows CBREAK on line 104 of a file term.h. This is in a macro definition for what is ordinarily the perfectly fine curses library function crmode(). But nowhere in the rn sources do I see a line like #include <curses.h>, so I guess Larry Wall is "rolling his own." But the Makefile does have the -lcurses.h option in there. Suddenly things are looking pretty strange. I grep'ed around for a while in /usr/include and /usr/include/sys, and I couldn't find CBREAK defined in any header files there. Oh, I saw a few things that looked like CBREAK, sort of, but before I try anything really ugly I thought I would ask the net if I am doing something stupid. I ran the Configure shell script, and everything seemed legitimate. Is rn supposed to be an easy install under 386/ix? Or am I blowing it? Please post and/or mail, I'll summarize if the answer doesn't appear here. Dan Mocsny dmocsny@uceng.uc.edu
cpcahil@virtech.uucp (Conor P. Cahill) (03/14/90)
In article <3975@uceng.UC.EDU> dmocsny@uceng.UC.EDU (daniel mocsny) writes: > Is rn supposed to be an easy install under 386/ix? Or am I blowing it? I compiled and loaded rn (patchlevel 40) without any problems that I can rember. In fact CBREAK is not even in my intrp.c file. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
mike@alt.sub.org (Mike Hoffmann) (03/15/90)
In article <3975@uceng.UC.EDU> dmocsny@uceng.UC.EDU (daniel mocsny) writes: >"intrp.c" line 538, CBREAK undefined. > >Grep'ing the sources shows CBREAK on line 104 of a file term.h. This is >in a macro definition for what is ordinarily the perfectly fine curses >library function crmode(). But nowhere in the rn sources do I see a line >like #include <curses.h>, so I guess Larry Wall is "rolling his own." >But the Makefile does have the -lcurses.h option in there. Suddenly things >are looking pretty strange. >dmocsny@uceng.uc.edu I stumbled into that one too!}i Then I wondered why the system used CBREAK at all, as it's doesn't occur in Sys V termio.h. So I started from scratch and watched the Configure script closely and LO! it didn't use termio at all, but sgtty instead. I looked into the the script and found a weird expression checking for existence of /usr/include/termio.h and then some other stuff. (I remember "sun" was in that line, it's all archived and tugged away, and I haven't got the time to unpack it now) I discarded everything after the check for termio.h that followed in that line, ran it all again and presto! Configure found termio.h OK and then it all wen't smoothly. Hope this helps! Mike -- ! Mike Hoffmann ! It's difficult ! UUCP: ! ! Fasangartenstr.102 ! to soar with Eagles ! ...!unido!altger!mike ! ! D-8000 Munich 90 ! when you have to ! SUB: ! ! West Germany ! work with Turkeys ! ...!altger!chiuur!krondor!mike !
dmocsny@uceng.UC.EDU (daniel mocsny) (03/16/90)
Here is a progress report on my problems with rn (actually remote rn) patchlevel 44 under 386/ix. I have gotten rn to compile, thanks to some timely advice from Eric Schnoebelen. I think rn is trying to run, also, but I am having trouble with getting the nntp stuff to connect to my article server machine. But I think I have to get the sysadmins on that machine to put me in some sort of permissions file, so I don't know if I really have a problem yet. Anyway, if anyone has run remote rn in client mode under 386/ix and had problems, please do tell us about them. The nntp stuff that comes with remote rn says all kinds of ominous things about trying to get the software to run under AT&T UNIX, but I couldn't tell immediately if the problems are supposed to be with the server or client mode. I also had several requests for help from other people who are trying to install rn under 386/ix. Apparently, patchlevel 44 has some stuff that breaks under 386/ix. Eric says he is putting together some fixes to send off to Stan Barber, the Keeper of rn. I hope he finds time to do this before the next person gets bit :-). Also, one person asked me where to get rn. I got mine via anonymous ftp from dartvax.dartmouth.edu, 129.170.16.4. Dartmouth has the version of rn patched up for remote use with nntp. If you want "straight" rn to use on a machine with B news or C news, many archive sites have it, for example tut.cis.ohio-state.edu, 129.146.8.60. For a recent list of ftp-able archive sites, see the newsgroup comp.misc. But whatever, watch out for patchlevel 44. The following is a summary of problems, and what I did to "fix" them. The compiler first complained about a redeclaration of sprintf() in the file common.h. Since the rn sources always ignore the return type of sprintf, I commented out this line. The second problem resulted from the Configure shell script failing to detect <termio.h> on 386/ix. This caused it to output an #undef TERMIO preprocessor directive to the file config.h. This in turn led to ugly things in the file intrp.c, indirectly through the term.h header file, which has some conditional compiles driven by TERMIO. To fix this, I had to change the #undef to #define TERMIO in config.h. The next problem stemmed from my old friend, the change window size stuff. Rn supports dynamically changeable window sizes, very handy if you are running X. But the Configure shell script on my system didn't seem to pick up all the correct system header files, which I think are (don't quote me) ptem.h, pty.h, and termio.h (right, I had termio.h by now, but not the other ones that do all the winsize stuff). Anyway, since I'm not running X window, I need variable window sizes about like I need a hole in the head, so I just undef'ed TIOCGWINSZ somewhere before the #ifdef TIOCGWINSZ statement in term.c, I believe around line 137. Rn wasn't about to give up without a fight. The file <signal.h> which gets #include'd in various places #defines a SIGWINCH code for telling signal() about a changed window size. So rn has some conditional compiles driven by SIGWINCH, that aren't going to be happy if TIOCGWINSZ is dead. So I had to gun those down too. The next problem was better, and fortunately about this time I got the letter from Eric, or I would have been dead in the water. Rn seems to be written with Berkeley UNIX directory structures in mind, and this causes problems in the program util.c. The way to fix them is to #include <dirent.h> in ndir.h, preferably somewhere that the preprocessor will get to, for example after the #ifndef USENDIR directive. A related problem was that util.c, ndir.c, and ngdata.c declare a struct direct, and Eric said that had to become struct dirent. I thought the easiest way to do that would be to stick a #define direct dirent directive in ndir.h, right after the #include <dirent.h>. I grepped ahead to make sure this wouldn't have undesirable side effects. That looked like the end of the rn problems. Now I had problems with the clientlib.c code in the nntp distribution, that the Makefile for remote rn wants to compile and link in. The problem was a whole bunch of functions don't get found. One of these was the Berkeley index() string function, which is equivalent to AT&T strchr(). And lo! The nntp people had already put a nice #ifdef USG in the code to #define index strchr for me. But the remote rn Makefile didn't get the USG message to cc when it compiled clientlib.c. The remaining un-found functions were the tcp/ip stuff in /usr/include/libinet.a. All I had to do was stick an -linet in the right spot in the Makefile, and things were dandy. To be on the safe side, I #include'd every header file that looked related, e.g., <netdb.h>, <sys/socket.h>, <netinet/in.h>, <arpa/inet.h>, <sys/types.h>, <sys/bsdtypes.h>, and <net/errno.h>. No doubt someone will tell me now that at least two of those files are mutually incompatible, and will instantly undergo mutual annihilation if they so much as land on the same file system. Well, I don't know, it compiled and ran, at least up to the opening screen. So now I have to go bother the guys on the server machine, so I can progress to the next level of errors. Anyway, I hope that clears things up. Thanks again everyone for the help, and let's do get those patches off to Stan, Eric, please. Dan Mocsny Snail: Internet: dmocsny@uceng.UC.EDU Dept. of Chemical Engng. M.L. 171 513/751-6824 (home) University of Cincinnati 513/556-2007 (lab) Cincinnati, Ohio 45221-0171 Virtual reality is like taking a shower in a raincoat.