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
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