On 2012-06-04 at 22:40 -0500, George R. Kasica wrote:
> OK...did the make distclean and make makefile after the edits here and
> then make.
>
> Results of each below - sadly not successful:
So, without knowing how things fit together on a system using libc from
12 years ago, in 2000, just after C99 came out and before the GNU folks
settled on how to make 64-bit arithmetic available, I can't say exactly
what your system needs. I can walk through what is supposed to happen.
We need the 64-bit types available. On BSD systems, the types are just
available. The GNU libc guards it behind __USE_ISOC99, but <features.h>
will undef that and then redefine it, based upon which
_SINGLE_LEADING_UNDERSCORE options it sees at the time it is invoked.
You need to analyse your /usr/include/features.h carefully.
On current Linux, defining _GNU_SOURCE is sufficient to enable both
__USE_ISOC99 and the other features which Exim (and most software)
assumes to be available. This is the comment in the file:
----------------------------8< cut here >8------------------------------
__STRICT_ANSI__ ISO Standard C.
_ISOC99_SOURCE Extensions to ISO C89 from ISO C99.
_POSIX_SOURCE IEEE Std 1003.1.
_POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2;
if >=199309L, add IEEE Std 1003.1b-1993;
if >=199506L, add IEEE Std 1003.1c-1995;
if >=200112L, all of IEEE 1003.1-2004
if >=200809L, all of IEEE 1003.1-2008
_XOPEN_SOURCE Includes POSIX and XPG things. Set to 500 if
Single Unix conformance is wanted, to 600 for the
sixth revision, to 700 for the seventh revision.
_XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions.
_LARGEFILE_SOURCE Some more functions for correct standard I/O.
_LARGEFILE64_SOURCE Additional functionality from LFS for large files.
_FILE_OFFSET_BITS=N Select default filesystem interface.
_BSD_SOURCE ISO C, POSIX, and 4.3BSD things.
_SVID_SOURCE ISO C, POSIX, and SVID things.
_ATFILE_SOURCE Additional *at interfaces.
_GNU_SOURCE All of the above, plus GNU extensions.
_REENTRANT Select additionally reentrant object.
_THREAD_SAFE Same as _REENTRANT, often used by other systems.
_FORTIFY_SOURCE If set to numeric value > 0 additional security
measures are defined, according to level.
----------------------------8< cut here >8------------------------------
So, in os.h, *before* the line which pulls in <features.h>, you need to
define whichever macros will cause <features.h> to enable the magic juju
flags which GNU libc requires to do what pretty much every other libc
just does by default. I don't know what things were like in that first
year after C99 on Linux: at the time, I was working for a company which
used FreeBSD and Solaris for the production systems. Clearly, things
have changed since then.
Alternatively, you might be able to rip the <features.h> line out of
os.h-Linux and replace it with the sort of thing which os.h-HP-UX has:
----------------------------8< cut here >8------------------------------
#define LLONG_MIN LONG_LONG_MIN
#define LLONG_MAX LONG_LONG_MAX
----------------------------8< cut here >8------------------------------
It won't be the same, but perhaps whatever it is in
/usr/include/limits.h that is being guarded by the flags which we're not
setting by default for that system.
We provide lots of ways for folks to adjust Exim to run on various
systems. But the further you are from a mainstream environment, the
more likely it is that you'll need to be able to pick apart the C
include files which your environment has.
As I said before, if it's something sane we can set to enable this to
work by default for you, which isn't likely to break other Linux setups,
we'll set it. We want Exim to work as well as possible for everyone.
We don't break arbitrarily. But we are going to change things as time
goes by, and whenever something changes, there is the risk of breakage.
The lack of 64-bit arithmetic was beginning to affect some users and we
felt it was worth the risk of issues to add support. We did it in such
a way as to have escape hatches, multiple escape hatches, to deal with
systems other than the main ones. That might be redefining the types,
it might be providing missing constants, but the options are there.
Yes, Exim 4.77 worked for you. Exim 4.77 had 32-bit arithmetic which
was not enough for some reasonable use-cases. We're not going to freeze
unchanging, never daring to support what our current users need, for
fear that it will break ancient systems, but we'll continue to work to
support those systems too, if the people who run them can work with us
to achieve that.
We have Exim building on environments which are not POSIX by default; we
introduce some POSIX assumption, it's caught during Release Candidate
testing, we provide workarounds to get things working again.
-Phil
managing to get
