#7328 closed Feature Requests (fixed)
Boost fails to Build with gccxml / msvc9
Reported by: | Owned by: | Neil Groves | |
---|---|---|---|
Milestone: | Boost 1.56.0 | Component: | range |
Version: | Boost 1.51.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Heya,
I am trying to use gccxml on Boost for a python project i want to build.
I ran a freshly-built-from-cvs gccxml:
"C:\Projects\gccxml\bin\release\gccxml.exe" -D"_HAS_TR1=0" --gccxml-compiler msvc9 -I... -I... -D"BOOST_HAS_THREADS" -D"BOOST_HAS_WINTHREADS" -D"__GCCXML__" "C:\Projects\python-ogre\code_generators\ogre\python_ogre.h" -fxml="ogre_1.7.2_cache.xml
(which points to)
#include "boost/python.hpp" #include "boost/python/ssize_t.hpp"
It fails:
boost_1_51_0/boost/range/concepts.hpp:177: error: 'bool mpl_::operator==(mpl_::failed, mpl_::failed)' cannot appear in a constant-expression
And i am honestly far from understanding what went wrong. It might be connected to gccxml not setting the correct version number, as i already had Problems like #4464 using the same setup.
Can anyone please give me a hint?
Change History (5)
comment:1 by , 10 years ago
Type: | Support Requests → Feature Requests |
---|
comment:2 by , 10 years ago
wrong prantheses. here:
#ifdef __GNUC__ // GNUC 4.2 has strange issues correctly detecting compliance with the Concepts // hence the least disruptive approach is to turn-off the concept checking for // this version of the compiler. #if __GNUC__ == 4 && __GNUC_MINOR__ == 2 #define BOOST_RANGE_ENABLE_CONCEPT_ASSERT 0 #endif #endif #ifdef __GCCXML__ // similar GNUC 4.2 issues for gccxml #if __GCCXML_GNUC__ == 4 && __GCCXML_GNUC_MINOR__ == 2 #define BOOST_RANGE_ENABLE_CONCEPT_ASSERT 0 #endif #endif
comment:3 by , 10 years ago
Component: | Building Boost → range |
---|---|
Owner: | set to |
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:5 by , 9 years ago
Milestone: | To Be Determined → Boost 1.56.0 |
---|
Note:
See TracTickets
for help on using tickets.
I did avoid this Problems by disabling the assertions. Since my gccxml is based on gcc 4.2.1, i suspect it should just be added to the compiler blacklist at the top of boost/range/concept.hpp, pretty similar to the gcc block {{ after this: #ifdef GNUC
#endif
add this: #ifdef GCCXML
#endif }} I do have an easy fix for similiar issues in iterator/iterator_concepts.hpp, but it can be done with similar blacklisting. I dont know, however, if this is the right place for workarounds, maybe there is a more "central" way to fix this.