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
> 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
- 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk