[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 > 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? > 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, 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. > 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? Rather than try to extract a clear question out of this <wink>, 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 weren't really needed, and won't be needed again).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4