From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 05:01:18
From: "Tim Peters" <tim.one_at_[hidden]>
> [David Abrahams]
> > 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 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.
> Yes. Python cares about the conceptual type, not about how a platform
> spells it.
> > 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
> What problem?
Uh, sorry. Depending on the order of #includes, Python's headers can
confuse Boost's configuration.
> > until I tried linking something at LLNL where they're using an older
> > Two translation units had different ideas of BOOST_HAS_LONG_LONG,
> Why was that? Nothing you showed us for it, unless there's an implied
> #include of Python.h before the Boost limits.h block you did show us.
Because one translation unit said (in effect):
#include <Python.h> // defines ULONGLONG_MAX
#include <boost/config.hpp> // decides long long is available
and the other said:
#include <boost/config.hpp> // decides long long is unavailable
#include <Python.h> // defines ULONGLONG_MAX (harmless this time)
> > so linking failed when one of them was looking for the long long
> > 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?
> Rather than try to extract a clear question out of this <wink>,
Too late (I hope!)
> let me turn
> it around: would your problem go away if this code in LongObject.h went
> away entirely? Python has no business defining ULONG_MAX anymore (that's
> left over from K&R C days), and I'm sure I got rid of all uses of
> LONGLONG_MAX and ULONGLONG_MAX in 2.2 (I vaguely recall some; they
> really needed, and won't be needed again).
Actually, that was the answer I was hoping you'd come up with. I'd also
suggest prefixing HAVE_LONG_LONG with some kind of PYTHON_ grist to keep it
out of the way of more-naive applications, but I don't want to push my luck
\<wink> -- I still remember what happened when I suggested that _Py_...
names should be avoided!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk