From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2005-06-20 02:41:16
David Abrahams wrote:
> Markus Schöpflin <markus.schoepflin_at_[hidden]> 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