[comp.unix.i386] rn on 386/ix.

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.