Re: [exim] Exim 4.8 build issue

Pàgina inicial
Delete this message
Reply to this message
Autor: Phil Pennock
Data:  
A: George R. Kasica
CC: exim-users, Todd Lyons, gkasica, Jeremy Harris
Assumpte: Re: [exim] Exim 4.8 build issue
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