From: David Abrahams (dave_at_[hidden])
Date: 2005-06-19 13:09:43
Markus Schöpflin <markus.schoepflin_at_[hidden]> writes:
> David Abrahams wrote:
>> "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]> writes:
>>>>This is pretty bad because quite a few boost libraries depend on more than
>>>>only the C names as specified in the standard. (thread and fs at least,
>>>>IIRC, but I think there are more)
>>>In the hot days of Boost.Python development we were very careful to use only
>>>ANSI features. Anything else is non-portable and bound to break somewhere,
>>>sooner or later. I.e. I think the libraries that don't compile with -std
>>>strict_ansi should be fixed.
>> pthreads is an extension to what's required by ANSI. I think that
>> might make Boost.Threads impossible.
> Well, every boost library that relies on more than ANSI would be
> affected. That is at least filesystem, thread and test because each of
> them needs some POSIX feature to work properly.
> And CXX is quite strict in strict ansi mode. Nothing is there besides
> the things promised in the standard. For boost.test for example that
> means, including <signal.h> doesn't give you sigaction, even not if the
> POSIX feature macros say it's there.
> 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
struct ios_traits // the working version
to work around brokenness.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk