Re: [boost] Config questions for GCC 3.1

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-11 07:01:00

I think I may have discovered what was causing this problem. The Python
headers contain this riff:

#ifdef HAVE_LONG_LONG

/* Hopefully this is portable... */
#ifndef ULONG_MAX
#define ULONG_MAX 4294967295U
#endif
#ifndef LONGLONG_MAX
#define LONGLONG_MAX 9223372036854775807LL
#endif
#ifndef ULONGLONG_MAX
#define ULONGLONG_MAX 0xffffffffffffffffULL
#endif

In other words, Python uses its config info to detect whether long long is
supported, then sets HAVE_LONG_LONG. If you #include <Python.h>, it then
sets all of the constants we use to detect the presence of long long. I'm
not certain that this is what's happening, but I wouldn't be too surprised
if on the platforms I was looking at, limits.h didn't define ULONG_MAX at
all, and Python's header got in the translation unit first to "correct the
misunderstanding" in one case.

Not sure if there's anything practical we can do about it, though ;-(

-Dave

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>

> In addition to these problems, I'm having an issue with how we're setting
> BOOST_HAS_LONG_LONG. When I compile Boost.Python with KCC on OSF, one
> translation unit comes out with this macro defined, and another comes out
> with it undefined. I'm not yet sure about the causes of this problem.