Re: [exim] Exim 4.8 build issue

Phil:

I've added the supplied items below as shown and still get this error
(doesn't look any different than previously) but I'm by no means a
programmer etc. What am I missing here?

expand.c: In function 'eval_op_mult':
expand.c:3196:25: error: 'LLONG_MIN' undeclared (first use in this
function)
expand.c:3196:25: note: each undeclared identifier is reported only
once for each function it appears in
expand.c:3200:28: error: 'LLONG_MAX' undeclared (first use in this
function)
expand.c: In function 'expand_string_integer':
expand.c:6178:17: error: 'LLONG_MAX' undeclared (first use in this
function)
expand.c:6178:43: error: 'LLONG_MIN' undeclared (first use in this
function)
make[1]: *** [expand.o] Error 1
make[1]: Leaving directory
`/mnt/scsi-1/Linux/exim-4.80/build-Linux-i386'
make: *** [all] Error 2


vi os.h-Linux


/* Exim: OS-specific C header file for Linux */

/* Some old systems we've received bug-reports for have a <limits.h>
which
does not pull in <features.h>. Best to just pull it in now and have
done
with the issue. */

#include <features.h>


#define CRYPT_H
#define GLIBC_IP_OPTIONS
#define HAVE_MMAP
#define HAVE_BSD_GETLOADAVG
#define HAVE_SYS_STATVFS_H
#define NO_IP_VAR_H
#define SIG_IGN_WORKS

#define int_eximarith_t int32_t
#define PR_EXIM_ARITH "%" PRId32
#define SC_EXIM_ARITH "%" SCNi32
#define SC_EXIM_DEC "%" SCNd32



>On Sun, 3 Jun 2012 10:45:50 -0400, you wrote:

>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