rn on 386/ix.

[daniel mocsny]

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 at 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.