Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> writes:
Boost.Python fails to build with MSVC 6.x/STLPort (see http://tinyurl.com/4nl7l) due to the following (incorrect) configuration logic in "boost/python/detail/config.hpp":
// The STLport puts all of the standard 'C' library names in std (as far as the // user is concerned), but without it you need a fix if you're using MSVC or // Intel C++ # if defined(BOOST_MSVC_STD_ITERATOR) # define BOOST_CSTD_ # else # define BOOST_CSTD_ std # endif
The issue, as explained in "boost/config/stdlib/stlport.hpp" is that:
// STLport does a good job of importing names into namespace std::, // but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since our // workaround does not conflict with STLports:
Is there a reason why we are not using BOOST_NO_STDC_NAMESPACE here?
I'm sorry, I don't remember the original rationale, I don't know how you'd use BOOST_NO_STDC_NAMESPACE,
#if defined(BOOST_NO_STDC_NAMESPACE) # define BOOST_CSTD_ #else # define BOOST_CSTD_ std #endif
and I don't see how this affects STLPort, since BOOST_MSVC_STD_ITERATOR isn't defined for STLPort... is it?
It's defined for Dinkumware that is shipped with VC 6.x, and you seem to be using it as an ad-hoc test for whether the C libary functions are in the global namespace or not.
In the past, it wasn't defined when STLPort was used with vc6.x. I know this because Boost.Python used to work with STLPort. I'd be surprised if the change to that macro didn't break other code. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com