DCC version 1.3.47/2.3.47 released

Vernon Schryver vjs@calcite.rhyolite.com
Thu Feb 1 15:37:13 UTC 2007


Perhaps the MIME fixes in the DCC client code are significant.  The
graphs of the DCC servers of the organziations that installed the new
version yesterday or last night are showing better spam detection rates.


> From: Gary Mills 

> > Shouldn't the sendmail makefiles generate both 32-bit and 64-bit libraries?
> > Or use `isainfo` and other probing to generate only 64-bit libraries?
>
> Configuration is manual with sendmail.  You specify compiler options
> directly, so it can generate any type of executable that you want.

I think configuration with sendmail is about as manual as with the DCC
source.  I put -g in conf_libmilter_ENVDEF and conf_sendmail_ENVDEF
but it has been years since I've done more for sendmail comiler switches,
if ever.

Speaking of sendmail, I forgot to flog the change in dccm that uses the
milter changes in sendmail 8.14 to react to dictionary attacks and
adjust the DCC Reputation of attacking IP addresses.  The final, official
version of 8.14.0 was released last night.


> In that case, all you can do is to provide reasonable defaults.  For
> Solaris, the usual default is 32-bit objects, even if the system is
> capable of running 64-bit objects.  For Linux, the opposite is true.

And IRIX, FreeBSD, and all other UNIX systems I've encountered recently
that can do 64-bits.

> It's a difference in philosophy.

It looks more like difference in levels of confusion.  Even without the
gcc vs. Sun Studio (or whatever it's called) conflicts in compiler
options, Sun's zillions of -xarch settings show a fundamental lack of
clarity of intentions.  Or perhaps internal conflicts on whether
the costs of 64-bit pointers and numbers are worth their benefits.


> The problem with configure using `isainfo -b' to decide whether to
> build 64-bit objects is that it doesn't determine my intention.  It
> assumes that I'm going to run the software on the same machine where
> I'm building it, and that I want 64-bit objects if they are possible.
> For me, both of these assumptions are incorrect.

I've long since consciously chosen to not worry about making the DCC
./configure stuff friendly to cross compiling.  I think cross compiling
is too hard.  I'm glad if it works, but make no promises.


> > Did you try running ./configure with whatever CFLAGS and LIBS set
> > in the enviroment are the opposite of -xarch=generic64?  
>
> The opposite would be the compiler default of -xarch=v8plus.  No, I
> didn't try that.
>
> > Perhaps I could change the ./configure script to look in $CFLAGS for
> > any of -m32, -m64, or -xarch string and if found, not add -m64 or -xarch=*
>
> The reverse would be better, in the case of Solaris.  Honour the compiler
> defaults.

DCC clients and DCC servers with less than 4 GByte of RAM do best with
the Solaris preference for 32 bits.  64-bit pointers and numbers only
waste memory bandwidth and other, perhaps less critical resources if
the application deals with less than 2 GBytes of data.  However, dccd
on a host with more than 4 GByte of RAM is the relatively rare application
that needs to use 64-bit pointers.

I think in the next release I'll
  - only test -m64, etc when there -m32, -m64, nad -xarch are not in the
      environment CFLAGS
  - change the test program that ./configure compiles and runs to fail if
      sizeof(off_t) and size(void*) are not equal to 8.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.