Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!uceng!dmocsny From: dmocsny@uceng.UC.EDU (daniel mocsny) Newsgroups: comp.unix.i386 Subject: Re: rn on 386/ix. Keywords: install, crunch, magic incantations Message-ID: <3993@uceng.UC.EDU> Date: 15 Mar 90 22:12:38 GMT References: <3975@uceng.UC.EDU> Organization: College of Engg., Univ. of Cincinnati Lines: 105 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 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 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 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 . 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., , , , , , , and . 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.