Bugzilla – Full Text Bug Listing |
Summary: | Bindings failure in core (traced-value) with older gcc | ||
---|---|---|---|
Product: | ns-3 | Reporter: | jframos45 |
Component: | build system | Assignee: | Gustavo J. A. M. Carneiro <gjcarneiro> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jframos45, jpelkey, mathieu.lacage, ns-bugs, tomh |
Priority: | P5 | ||
Version: | ns-3-dev | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | patch |
Description
jframos45
2010-07-17 13:17:53 UTC
Sounds like the older sequence-number.h header file is being used instead of the new one. Could you try ./waf distclean and then build from scratch? I have run: > ./waf clean > ./waf distclean > ./waf -d debug configure > ./waf and same error... The old sequence-number.h file was still lying around. It should not have been included, this sounds like a compiler bug, but just in case I removed it from the tree. Otherwise I really don't know what to say. Probably a compiler bug? Maybe try with another compiler version to see if that's the cause? I have updated the ns-3-dev repository and now it don´t start to build. > ./waf clean > ./waf distclean > ./waf configure > ./waf Waf: Entering directory `/bin/ns-3-dev/build' '/bin/ns-3-dev/bindings/python/ns3/__init__.py' -> '/bin/ns-3-dev/build/debug/bindings/python/ns3/__init__.py' Waf: Leaving directory `/bin/ns-3-dev/build' source not found: 'sequence-number.cc' in 'dir:///bin/ns-3-dev/src/internet-stack' I will try with another compiler version... Thanks. There is something wrong in your tree; the wscript is referencing files, but those references should have been removed already... have you tried a fresh checkout? OK!! The wscript file wasn´t updated because I modified it to "NSC" acept IA64 architecture. I deleted and re-updated it and the problem was fixed! But... Now I have another error: cc1plus: warnings being treated as errors debug/ns3/traced-value.h: In member function âns3::TracedValue<T>::operator ns3::EnumValue() const [with T = double]â: debug/bindings/python/ns3_module_core.cc:21494: instantiated from here debug/ns3/traced-value.h:88: warning: passing âconst doubleâ for argument 1 to âns3::EnumValue::EnumValue(int)â debug/ns3/traced-value.h: In member function âns3::TracedValue<T>::operator ns3::IntegerValue() const [with T = double]â: debug/bindings/python/ns3_module_core.cc:21848: instantiated from here debug/ns3/traced-value.h:73: warning: passing âconst doubleâ for argument 1 to âns3::IntegerValue::IntegerValue(const int64_t&)â debug/ns3/traced-value.h: In member function âns3::TracedValue<T>::operator ns3::UintegerValue() const [with T = double]â: debug/bindings/python/ns3_module_core.cc:25231: instantiated from here debug/ns3/traced-value.h:78: warning: passing âconst doubleâ for argument 1 to âns3::UintegerValue::UintegerValue(const uint64_t&)â [1201/1345] cxx: build/debug/bindings/python/ns3_module_energy.cc -> build/debug/bindings/python/ns3_module_energy_3.o Waf: Leaving directory `/bin/ns-3-dev/build' Build failed: -> task failed (err #1): {task: cxx ns3_module_core.cc -> ns3_module_core_3.o} Thanks. (In reply to comment #6) > OK!! > The wscript file wasn´t updated because I modified it to "NSC" acept IA64 > architecture. I deleted and re-updated it and the problem was fixed! > > But... > Now I have another error: > > > cc1plus: warnings being treated as errors > debug/ns3/traced-value.h: In member function âns3::TracedValue<T>::operator > ns3::EnumValue() const [with T = double]â: > debug/bindings/python/ns3_module_core.cc:21494: instantiated from here > debug/ns3/traced-value.h:88: warning: passing âconst doubleâ for argument 1 to > âns3::EnumValue::EnumValue(int)â > debug/ns3/traced-value.h: In member function âns3::TracedValue<T>::operator > ns3::IntegerValue() const [with T = double]â: > debug/bindings/python/ns3_module_core.cc:21848: instantiated from here > debug/ns3/traced-value.h:73: warning: passing âconst doubleâ for argument 1 to > âns3::IntegerValue::IntegerValue(const int64_t&)â > debug/ns3/traced-value.h: In member function âns3::TracedValue<T>::operator > ns3::UintegerValue() const [with T = double]â: > debug/bindings/python/ns3_module_core.cc:25231: instantiated from here > debug/ns3/traced-value.h:78: warning: passing âconst doubleâ for argument 1 to > âns3::UintegerValue::UintegerValue(const uint64_t&)â > [1201/1345] cxx: build/debug/bindings/python/ns3_module_energy.cc -> > build/debug/bindings/python/ns3_module_energy_3.o > Waf: Leaving directory `/bin/ns-3-dev/build' > Build failed: -> task failed (err #1): > {task: cxx ns3_module_core.cc -> ns3_module_core_3.o} > > > Thanks. I can confirm this on g++-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu5) I have gcc/g++ (GCC) 4.1.2 20070115 (SUSE Linux) I can reproduce by compiling with GCC 4.1. Now this is a weird bug. traced-value.h contains: template <typename T> class TracedValue { [...] TracedValue (const EnumValue &value) : m_v (value.Get ()) {} operator EnumValue () const { return EnumValue (m_v); } [...] }; Consequently, the bindings apidefs contains: ## traced-value.h: ns3::TracedValue<double> [class] root_module['ns3::TracedValue< double >'].implicitly_converts_to(root_module['ns3::EnumValue']) And so, the generated constructor for ns3::TracedValue<double> contains: PyObject *arg0; ns3::EnumValue arg02; const char *keywords[] = {"arg0", NULL}; [...] if (PyObject_IsInstance(arg0, (PyObject*) &PyNs3EnumValue_Type)) { arg02 = *((PyNs3EnumValue *) arg0)->obj; } else if (PyObject_IsInstance(arg0, (PyObject*) &PyNs3TracedValue__Double_Type)) { arg02 = *((PyNs3TracedValue__Double *) arg0)->obj; ///// error here } else { [...] } self->obj = new ns3::EnumValue(arg02); return 0; } ((( "((PyNs3TracedValue__Double *) arg0)->obj" is of type ns3::TracedValue< double > * ))) So I really don't get the compiler error, the bindings code should be correct. With template <typename T> class TracedValue { operator EnumValue () const { return EnumValue (m_v); } [...] T m_v; } With instantiation for double, it becomes: class TracedValue... { double m_v; operator EnumValue () const { return EnumValue (m_v); } } We are thus passing a double for a constructor accepting int. Loss of precision possible. The compiler warns. The templated code is too generic, it's not python bindings fault, I think. Mathieu? I have builded other GCC version [4.3.3] and this problem is fixed, but I think is a possible bug... (In reply to comment #10) > With > > template <typename T> > class TracedValue > { > operator EnumValue () const { > return EnumValue (m_v); > } > > [...] > T m_v; > } > > With instantiation for double, it becomes: > > class TracedValue... > { > double m_v; > operator EnumValue () const { > return EnumValue (m_v); > } > } > > We are thus passing a double for a constructor accepting int. Loss of > precision possible. The compiler warns. The templated code is too generic, > it's not python bindings fault, I think. > > Mathieu? I do not remember why this template bothers with defining these implicit conversion operators. reopening-- this will affect gcc-4.1 or older machines (if we are still supporting those compilers, we need to fix this bindings issue) Created attachment 958 [details]
patch
I tried removing some implicit constructor / conversion operator, and rescan python bindings, and then NS-3 builds fine with GCC 4.1.
Mathieu, OK to apply the patch (except remove the lines instead of comment them) ?
I think that they are needed to be able to declare a TracedValue<int> as an attribute IntegerValue for example. (In reply to comment #15) > I think that they are needed to be able to declare a TracedValue<int> as an > attribute IntegerValue for example. I'm not sure, but if true such functionality is not used currently in NS-3, because remove it and NS-3 builds fine. (In reply to comment #16) > (In reply to comment #15) > > I think that they are needed to be able to declare a TracedValue<int> as an > > attribute IntegerValue for example. > > I'm not sure, but if true such functionality is not used currently in NS-3, > because remove it and NS-3 builds fine. yes, but once people start using TracedValue, they will get in this mess. Maybe it would work to add instead the conversion constructor and operator to the attribute classes instead ? say, BooleanValue, et al. changeset 34e72f4cdd87 |