[Python-Dev] long long configuration

[David Abrahams]

Hi,

I recently came across a nasty configuration conflict between boost and
python.

In LongObject.h we have:

    #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

Well, it turns out that boost detects whether the compiler supports long
long by #including <limits.h> and looking for these macros:

#include <limits.h>
# if !defined(BOOST_MSVC) && !defined(__BORLANDC__) \
   && (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) ||
defined(ULONGLONG_MAX))
#  define BOOST_HAS_LONG_LONG
#endif

So it turns out that on some platforms, Python's configuration sets
HAVE_LONG_LONG even when limits.h doesn't include definitions of these
macros. For example, there's MSVC6, where Python substitutes __int64 for
long long using its LONG_LONG macro. However, I didn't actually notice the
problem until I tried linking something at LLNL where they're using an
older KCC. Two translation units had different ideas of
BOOST_HAS_LONG_LONG, so linking failed when one of them was looking for the
long long support supposedly provided by another. I'm surprised it wasn't a
worse problem with MSVC6, because after all, it doesn't even supply a type
called "long long".

Is there any chance that something can be done to prevent this sort of
conflict?

Thanks,
Dave