David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@web.de> writes:
So I think as long as the bug in iotraits is not fixed, boost.python will not work on this platform, at least not with the boost.build toolset. :-(
Note: when using Boost.Build you are supposed to #include one of its headers first. That means boost/python/detail/prefix.hpp gets #included before anything else, which gives you an opportunity to play all sorts of nasty tricks like
#define ios_traits broken_ios_traits #include <iotraits> #undef ios_traits
struct ios_traits // the working version {
}
to work around brokenness.
The problem is, there is no working version of iotraits in this case. To summarize: - The <iotraits> header file has broken support for std::fpos_t when it's not an integral value. - The definition of std::fpos_t is normally taken from /usr/include/stdio.h. - std::fpos_t as defined in stdio.h is not an integer value whenever _XOPEN_SOURCE >= 500. pyconfig.h forces the value to 600. - When the compiler option pure_cname is in effect and /usr/include is not on the command line as include path, a different stdio.h is selected, which defines std::fpos_t as an itegral value, ignoring the setting of _XOPEN_SOURCE. The last item is the explanation, why Ralf's setup works, because pure_cname is in effect by default whenever strict_ansi is in effect. Now, the bb toolset cannot use pure_cname because test, fs, threads and maybe others need POSIX features. And I don't see how playing tricks in some boost.python header file could help here. Do you have an idea? TIA, Markus