DCC version 1.3.11 released

> From: <dcc@mikecappella.com>

> The changes to include/dcc_config.h.in have broken building for my RH9
> system.  In particular, the change to defining HAVE_SA_LEN from undefined is
> killing the build, as it should not be defined.  There might be others.  I'm
> wondering why the defaults for all these config vars were changed to be set.

There are no such things as defaults in include/dcc_config.h except
for WIN32 systems.  include/dcc_config.h must always (except on Windwos)
be built from include/dcc_config.h.in by the ./configure script.
The ./configure script is the repository of all of the defaults.

`diff` says that the only change from the 1.3.10 include/dcc_config.h
through 1.3.12 include/dcc_config.h was the remove of the following lines
to include/dcc_defs.h:
    #ifdef __hpux
    #define seteuid(euid) setresuid(-1,euid,-1)
    #endif /* __hpux */
The only difference between the 1.3.10 and 1.3.12 include/dcc_config.h.in
files is that plus the use of ./configure variables for DCC_HOMEDIR,
DCC_LIBEXECDIR, and DCC_RUNDIR.  
It should make no difference to move the HPUX setting to dcc_defs.h
where it always belonged.  Fixing DCC_HOMEDIR, DCC_LIBEXECDIR, and
DCC_RUNDIR to be controlled by ./configure in the C programs as well as
the shell scripts should not matter, because the programs are rarely
run except from the scripts, but it is cleaner.  

The reason I wrote "1.3.12" instead of "1.3.11" is related to the
CHANGES excuse for 1.3.12:

    Fix packaging error in 1.3.11.

The script that makes the DCC tarballs uses my development include/dcc_config.h
file to generate a include/dcc_config.h suitable for WIN32 systems
(which generally can't run ./configure) and  a include/dcc_config.h.in
suitable for systems with a Bourne shell.  That consists of replacing
many #define lines with #undef lines, because ./configure is too dumb
to convert #define to #undef lines.  I did not notice my error in that
script until an hour or two after I put the 1.3.11 tarballs in the FTP
directories and then installed from them onto a Solaris system that
does not have something like u_int32_t.

I had hoped that few if anyone had found the 1.3.11 version on Sunday
morning before I replaced it with 1.3.12, and so said nothing.  I'm
leery of writing too many boring messages to this mailing list.

I hope that your problem will disappear in 1.3.12.


Vernon Schryver    vjs@rhyolite.com