Re: [exim] Exim 4.8 build issue

On 2012-06-03 at 09:02 -0500, George R. Kasica wrote:
> >On Sun, 3 Jun 2012 09:25:38 -0400, you wrote:
>
> >On 2012-06-03 at 06:52 -0500, George R. Kasica wrote:
> >> Trying to build Exim-4.8 here from the tar.gz and am getting the
> >> following error on make:
> >
> >Which operating system, which release?
> Kernel is now 3.3.7
>
> >
> >If a Linux variant, which libc, which version?
>
> Its a generic linux from scratch system more or less...startd out as a
> Caldera Open Linux way back in 1995 but with the demise of that it was
> converted over to a build from scratch on a new set of disks and the
> data copies over around 2001 and maintained and able to compile every
> version of exim up to now with no major issues.

Okay, so what's happened is that we've added support for 64-bit
arithmetic for ${eval...} on platforms which support it.

We define _GNU_SOURCE to be 1 before pulling in OS headers, which on
Linux includes <features.h>. On Linux, that enables _ISOC99_SOURCE
which enables __USE_ISOC99 and then in <limits.h> that, together with
__GNUC__, defines LLONG_MIN, LLONG_MAX and ULLONG_MAX.

That's what *should* happen on Linux, to get basic 64-bit arithmetic.

If you edit OS/os.h-Linux and add these:

/* -------------------------8< cut here >8--------------------------- */
#define int_eximarith_t int32_t
#define PR_EXIM_ARITH "%" PRId32
#define SC_EXIM_ARITH "%" SCNi32
#define SC_EXIM_DEC "%" SCNd32
/* -------------------------8< cut here >8--------------------------- */

then you *should* get 32-bit arithmetic back. If you do this, I advise
against using $tod_epoch_l in ${eval...} as you'll likely overflow; it's
the epoch time in microseconds since the epoch (as a string), which
arithmetic in 32-bits will not handle meaningfully.

Somewhere, you've diverged from the rest of Linux. If you can figure
out a decent *safe* way to detect what's different, we can try to handle
this automatically for you.

-Phil