From: "Tim Peters" <tim.one@comcast.net> > [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? 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 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. 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 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>, 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 weren't > 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! -Dave
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