> I would be perfectly happy, however, to be told exactly what has to be done
> to get the program to work in a Solaris 2.4 environment.
If anyone is interested in the resolution, the details follow.
The authors may be interested in a couple of things that might be done
to make the program work in a Solaris 2.4 environment. The wording in
the INSTALL file is unclear but seems to imply that this is the correct
forum in which to post fixes to the code:
1. First problem is getting a clean compile and link in Solaris 2.4.
The problem is that code in mmalloc/mrealloc.c will always define a
macro to replace calls to memmove to bcopy instead. This macro
definition is supposed to be conditional on HAVE_MEMMOVE not being
defined, however, nowhere is HAVE_MEMMOVE defined. I suspect that
on most systems, bcopy is present (in fact on Solaris 2.5 and later
bcopy is present without using the UCB libraries, so people running
a recent Solaris are OK.) Unfortunately, our FreeNet system does
not have software maintenance, so we're stuck running 2.4 for now.
I would suggest that mrealloc.c should be changed slightly, here
is the diff I made (both sets of diffs assume the 1.0.6.5 release
as of last evening):
fan1 [~/nntpcache-1.0.6.5/mmalloc] {zz999.19}% diff mrealloc.c mrealloc.c.ORIG
25,26d24
< #include "mmprivate.h"
<
29a28,29
>
> #include "mmprivate.h"
fan1 [~/nntpcache-1.0.6.5/mmalloc] {zz999.20}%
i.e. move the include which eventually includes config.h ahead of the
macro definition dependent on HAVE_MEMMOVE. This now allows one to
define HAVE_MEMMOVE in config.h and have the subroutine compile and link.
Ideally, HAVE_MEMMOVE should be added to config.h by the configure
script, however, I don't know enough about the script to figure out how
to do that and no documentation on configure appears to accompany nntpcache.
2. Second problem is a segment violation that occurs when you attempt to
start nntpcached with the -e flag. An inspection of the code indicates
that nntpcached will fail processing any command line flags because the
call to setproctitle in nntpcache.c just before the getopt loop will
trash the argv vector in a Solaris 2.4 (and probably other) systems.
I would suggest that the setproctitle call should be made after the
command line switches are safely processed and the following diff
does that:
fan1 [~/nntpcache-1.0.6.5] {zz999.24}% diff nntpcache.c nntpcache.c.ORIG
622a623,624
> initsetproctitle(argc, argv, envp);
> setproctitle("initialising");
658,660d659
<
< initsetproctitle(argc, argv, envp);
< setproctitle("initialising");
fan1 [~/nntpcache-1.0.6.5] {zz999.25}%
3. Third problem is that I copied the nntpcache directories to a new disk
partition yesterday using tar and tar sets the access time on all the
copied files. Once I got the program fixed, expire still didn't because
none of the files were old enough. The code in expire.c will use the
more recent of access or modification time to determine whether a file
should expire. For a caching server, I suppose this makes sense, so
I've temporarily changed the configure file to expire after 12 hours
just to clean things up and will go back to a two week expire once
I've gotten rid of the accumulated cache (about three months worth
by my guess.) Oh well... live and learn.
--
O- J. Anthony Fitzgerald, jaf@UNB.ca, http://www.unb.ca/csd/staff/jaf/ -O
