[3668] in linux-net channel archive
Re: Is anyone running INN successfully?
daemon@ATHENA.MIT.EDU (Patrick Main)
Sat Jul 13 12:53:27 1996
Date: Fri, 12 Jul 1996 18:47:24 -0300
To: Mark Menard <mark@capital.net>
From: Patrick Main <72254.3077@compuserve.com>
Cc: linux-admin@vger.rutgers.edu, linux-net@vger.rutgers.edu
>Ok, this could be some source of the problem. I am using Red Hat 3.0.3
>(gcc 2.7.2 and libc 5.2.18) with kernel 2.0.0. Is anyone using INN with
>Red Hat 3.0.3 (or gcc 2.7.2 and libc 5.2.18) and kernel >=2.0.
>
>Mark
>
-----------------------------------------------------------------------
Mark, I am using Red Hat 3.0.3 and Linux 2.0.3/4 and now running
Inn1.4unoff4 .... So far there were some fun and games involved in
getting a decent compile. An "easy" solution is to compile against
a different "source" tree. Compiling against a 1.3.57 tree produced a
runable INN for me. This is with MMAP enabled but skipping the shared
active patch <for now>. The major problem with first attempts was that
the nnrpd <in.nnrpd> would give a segment fault and do a core dump.
To test this ..from the FAQ run nnrpd by hand after setting up an
entry in nnrp.access to allow standard-in ie: " stdin:Read Post:::* "
Now you can run nnrpd or in.nnrpd at the command prompt to test.
Changing the source tree from linux2.0.3 to linux.1.3.57 and recompiling
INN reulted in binaries that worked.
I later traced down the warning messages when compiling against a 2.0
source tree and moving the #include <sys/time.h> entries near the "top"
of where they appear eliminated most warnings. Bottom line is i made sure
that the first includes were consistantly <sys/types.h> <stdio.h> then
<sys/time.h> after which other includes followed. Some of the includes
began with an Inn header file. Every file that included <sys/time.h> was
changed to the behavior of above. I also did a ifndef on one of the
includes in <sys> to avoid a MMAP related entry from becoming redefined...
it is defined in a <asm> include. However this last change i think was
unneeded since the define was only being changed from 0x00 to 0 maybe it
does make a diff?
Anyhow after all this the compile was much cleaner and nnrpd runs without
segment faulting. Now if i only understood why it is running?? ;-)
ps: i am running the improved nnrpd response patch and Crosspost is neat
look in doc for the man page or if you installed then "man crosspost"
Will try to trace down remaining compile warnings but with a light test feed
it has been up now for three days. News spool now about 150megs "light"
