abrams@bnlux0.bnl.gov (The Ancient Programmer) (07/26/89)
I previously posted this "Request for Assistance" in news.software.nntp and received a couple of replies which said: "It worked fine for me." So I got new versions of nntp.1.5 and rrn.39 from Berkeley's anonymous ftp and tried again with the same results! Does anyone have any idea why I am getting these results while others seem to be having no problem with the same code? Trying to install NNTP.1.5 & RRN.39 on a Sun 3 under OS 4.0.1. Problem #1: In RRN.39, Configure requires that response_codes.h be in the nntp/common source directory, and in the distribution it is not there. Getting past that - Problem #2: In util.c, signal is defined as: int (*signal())(); while in /usr/include/signal.h signal is defined as: void (*signal())(); This leads to an error during make of: |"util.c", line 36: redeclaration of signal |"util.c", line 64: warning: illegal pointer combination |"util.c", line 65: warning: illegal pointer combination |*** Error code 1 |make: Fatal error: Command failed for target `util.o' Problem #3: If I blunder past that problem by changing signal to void in util.c, I encounter the following: |make: Fatal error: Don't know how to make target `getactive.o' Has anyone else encountered these problems? If people have successfully gotten NNTP1.5/RNN39 working on Suns running SUNOS 4.0.1, what is different about my system? It is a vanilla SUNOS 4.0.1! Any help gratefully accepted. Thanks in advance. -- INTERNET: abrams@bnlux0.bnl.gov BITNET: abrams@bnlux0.BITNET UUCP: ...philabs!sbcs!bnlux0!abrams
guy@auspex.auspex.com (Guy Harris) (07/29/89)
>Problem #2: In util.c, signal is defined as: > int (*signal())(); It shouldn't be declaring "signal()" at all; it should simply be including <signal.h> and letting that include file declare it. This avoids barfage when you try to make your program work on both systems with the old-style notion that signal handlers return "int" and systems with the new-style notion that they return "void". (You may still get warnings from some compilers if you save the return value of "signal()" away in a variable declared in a different style, but those can generally be lived with.)