What's wrong with pybindgen in Cygwin?

[Weng Gavin]

With the new rev 564 of pybindgen in Cygwin(Python 2.5.1), the errors are listed as following:

 

[456/509] cxx: build/debug/bindings/python/ns3_module_common.cc -> build/debug/bindings/python/ns3_module_common_3.o
debug/bindings/python/ns3_module_common.cc: In function `PyObject* _wrap_PyNs3ListErrorModel_GetList(PyNs3ListErrorModel*)':
debug/bindings/python/ns3_module_common.cc:5571: error: no match for 'operator=' in 'retval = ns3::ListErrorModel::GetList() const()'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/list.tcc:121: note: candidates are: std::list<_Tp, _Alloc>& std::list<_Tp, _Alloc>::operator=(const std::list<_Tp, _Alloc>&) [with _Tp = unsigned int, _Alloc = std::allocator<unsigned int>]

debug/bindings/python/ns3_module_common.cc: In function `PyObject* _wrap_PyNs3ListErrorModel_SetList(PyNs3ListErrorModel*, PyObject*, PyObject*)':
debug/bindings/python/ns3_module_common.cc:5589: error: no matching function for call to `ns3::ListErrorModel::SetList(std::list<unsigned int, std::allocator<unsigned int> >&)'
debug/ns3/error-model.h:215: note: candidates are: void ns3::ListErrorModel::SetList(const std::list<uint32_t, std::allocator<uint32_t> >&)
Build failed
 -> task failed (err #129): [bld:///cygdrive/d/Study/WirelessCommunication/NS-3/
repos/ns-3-dev/bindings/python/ns3_module_common_3.o]

 

How to solve it?

Best wishes & kind regards from yours sincerely,
Gavin Weng

[Gustavo Carneiro]

I don't have cygwin installed, but I couldn't reproduce with mingw / g++ 3.4.5.

Can you send me the file build/debug/bindings/python/ns3_module_common.cc (possibly compressed)?  It might help me discover the problem...

Also, this is basically a bug report, bugzilla.nsnam.org is a better place to submit bug reports.

2008/8/28 Weng Gavin <gavi...@gmail.com>

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[Weng Gavin]

I'm not quite sure whether it's a bug or just anything wrong with my settings. By the way, Cygwin has g++ version 3.4.4.

 

Here is the file you requested. Thx a million!

Best wishes & kind regards from yours sincerely,
Gavin Weng

[Gustavo Carneiro]

The problem appears to be a mismatch between uint32_t and 'unsigned int'.  They are supposed to be the same type.  I don't know why cygwin thinks they aren't... :-(

2008/8/28 Weng Gavin <gavi...@gmail.com>

[Weng Gavin]

Then, how do we solve it?

Best wishes & kind regards from yours sincerely,
Gavin Weng

[Mathieu Lacage]

On Thu, 2008-08-28 at 21:37 +0800, Weng Gavin wrote:
> Then, how do we solve it?

you can monitor http://www.nsnam.org/bugzilla/show_bug.cgi?id=296 and
wait until craig (who introduced this problem) fixes it.

Another much more helpful option, would be, of course, to figure out
whether you can make this code work on osX, if so, what needs to be
done, provide a patch, and let craig apply it. At worst, craig will
disable this code on osX and cygwin.

temporarily, the option, is, of course, to edit src/simulator/wscript
and remove all mention of a realtime scheduler from there.

regards,
Mathieu

[Weng Gavin]

But this problem is quite different from the reported bug, which deals with simulator while the bug I observe is with Python Bindings or so? I'm wondering whether the python bindings are finalised till now.

Best wishes & kind regards from yours sincerely,
Gavin Weng

[Gustavo Carneiro]

2008/8/28 Mathieu Lacage <mathieu...@sophia.inria.fr>

Sure, this is _one_ problem.  However what is being reported here is actually a different problem.

It seems  gccxml is reporting types like std::list<uint32_t> as std::list<unsigned int>, and so python binding generated code is trying to handle vectors of type 'std::list<unsigned int>' instead.  Now, on all systems uint32_t and unsigned int are the same type.  But it seems that cygwin is an exception to that rule, since it typedefs uint32_t as 'unsigned long' instead of 'unsigned int', thereby causing a compilation error.

I have no idea yet how to fix this, unfortunately.  Sent an email to pygccxml-devel list to see if something comes up.

[Mathieu Lacage]

On Thu, 2008-08-28 at 17:30 +0100, Gustavo Carneiro wrote:

>
> It seems gccxml is reporting types like std::list<uint32_t> as
> std::list<unsigned int>, and so python binding generated code is
> trying to handle vectors of type 'std::list<unsigned int>' instead.
> Now, on all systems uint32_t and unsigned int are the same type. But
> it seems that cygwin is an exception to that rule, since it typedefs

the same build problem is visible on osX.

> uint32_t as 'unsigned long' instead of 'unsigned int', thereby
> causing a compilation error.

interesting. It looks like the bug is in gccxml or pybindgen usage of
gccxml: uint32_t should not be converted to unsigned int: you should be
able to detect that you have a typedef here and use the outer typedef
rather than the underlying type.

> I have no idea yet how to fix this, unfortunately. Sent an email to
> pygccxml-devel list to see if something comes up.

Mathieu

[Mathieu Lacage]

On Thu, 2008-08-28 at 09:34 -0700, Mathieu Lacage wrote:

> interesting. It looks like the bug is in gccxml or pybindgen usage of
> gccxml: uint32_t should not be converted to unsigned int: you should be
> able to detect that you have a typedef here and use the outer typedef
> rather than the underlying type.

I failed to explain why I think this is a bug in gccxml or pybindgen. If
you do what you do right now, what happens is that the typedefs are
effectively cast in stone when ./waf --python-scan is run which means
that we can't store in our repo the output of ./waf --python-scan
because all these typedefs are platform-specific and can all differ
subtly from platform to platform.

So, the alternatives are either we make ./waf --python-scan not use the
underlying types but use the typedef or we request users to run
--python-scan as part of their build procedure all the time (including
release tarballs). The latter is clearly highly undesirable. i.e., it's
going to be a very very hard sell :/

Mathieu

[Mathieu Lacage]

On Fri, 2008-08-29 at 00:29 +0800, Weng Gavin wrote:
> But this problem is quite different from the reported bug, which deals
> with simulator while the bug I observe is with Python Bindings or so?

and, yes, you are right. I mixed up things. see
http://www.nsnam.org/bugzilla/show_bug.cgi?id=298

sorry for the noise.

Mathieu

[Gustavo Carneiro]

2008/8/28 Mathieu Lacage <mathieu...@sophia.inria.fr>

On Thu, 2008-08-28 at 09:34 -0700, Mathieu Lacage wrote:

> interesting. It looks like the bug is in gccxml or pybindgen usage of
> gccxml: uint32_t should not be converted to unsigned int: you should be
> able to detect that you have a typedef here and use the outer typedef
> rather than the underlying type.

I failed to explain why I think this is a bug in gccxml or pybindgen. If
you do what you do right now, what happens is that the typedefs are
effectively cast in stone when ./waf --python-scan is run which means
that we can't store in our repo the output of ./waf --python-scan
because all these typedefs are platform-specific and can all differ
subtly from platform to platform.

I agree 100% with you.  However, I am not sure I can fix it.  Further investigation lead me to believe this is a bug in gccxml itself.  I reported it [1] and await to see what the maintainer thinks.


[1] http://www.gccxml.org/Bug/view.php?id=7572
 

So, the alternatives are either we make ./waf --python-scan not use the
underlying types but use the typedef

Like I said, nothing I can do in pybindgen side.  All we can hope for right now is to force pybindgen to ignore the container types for now, so that at least people can build ns-3.
 

or we request users to run
--python-scan as part of their build procedure all the time (including
release tarballs). The latter is clearly highly undesirable. i.e., it's
going to be a very very hard sell :/

After all this work, clearly we don't want to get to that point.

[Weng Gavin]

But actually in configuring result, pygccxml doesn't exist.

 

Checking for Python module pygccxml                                      : not f
ound

Best wishes & kind regards from yours sincerely,
Gavin Weng