Bugzilla – Bug 2778
Build issue on Mac when waf attempts to use non system version of python
Last modified: 2017-08-31 09:27:40 EDT
I dunno if this is fixable or not. It seems to fall into the category of user error but it presents itself in a way where it's difficult for people to diagnose the problem.
Several students in my class with Macs who had previously installed Anaconda were unable to build ns-3.26 and ns-3-dev. It is similar to this issue on the users forum.
"../src/wifi/model/wifi-phy.cc:65:46: error: no matching constructor for initialization of 'WifiPhy::ChannelToFrequencyWidthMap' (aka 'map<pair<unsigned short, ns3::WifiPhyStandard>, pair<unsigned int, unsigned int> >')
WifiPhy::ChannelToFrequencyWidthMap WifiPhy::m_channelToFrequencyWidth =
/usr/include/c++/4.2.1/bits/stl_map.h:188:9: note: candidate constructor template not viable: requires 2 arguments, but 79 were provided
map(_InputIterator __first, _InputIterator __last)
There were a few other versions of this but basically the problem was that waf was running using the python in Anaconda. As the google groups user reported it also leads to stuff like this:
../../../../anaconda/include/qt/QtCore/qstring.h:756:55: error: no type named
'u16string' in namespace 'std'
static inline QString fromStdU16String(const std::u16string &s);
i.e. the include path is getting messed up and it's grabbing anaconda's installed version of QT. I suspect the first error is also somehow related. Regardless the solution is to explicitly tell waf to use /usr/bin/python during the configure step. Then all of the errors magically go away. That said, I don't use python so there may be other issues that crop up later but it at least compiles.
I can confirm that Anaconda badly screws all the C++ includes.
I am more inclined to think that it's a problem in Anaconda tho.
I'll dig further when I will have some time.
I added help info about this to the Installation and Troubleshooting pages on our wiki, for the time being.