pybox2d fails to build on snow-leopard with swig error

[GoogleCodeExporter]

What steps will reproduce the problem?
1. follow the steps on the INSTALL file for mac osx

What is the expected output? What do you see instead?

running build
running build_py
copying ./__init__.py -> build/lib.macosx-10.6-i386-2.6/Box2D
running build_ext
building 'Box2D._Box2D' extension
swigging Box2D/Box2D.i to Box2D/Box2D_wrap.cpp
swig -python -c++ -IBox2D -O -includeall -ignoremissing -w201 -outdir . -o
Box2D/Box2D_wrap.cpp Box2D/Box2D.i
Box2D/Box2D_printing.i:29: Error: Syntax error in input(3).
error: command 'swig' failed with exit status 1

What version of the product are you using? On what operating system?
mac os 10.6 snow leopard, pybox2d-2.0.2b1, swig 1.3.40

Please provide any additional information below.

Original issue reported on code.google.com by jc.lo...@gmail.com on 7 Jan 2010 at 8:05

[GoogleCodeExporter]

Are you sure that's a clean SVN copy (or at least from the zipped source code)?
There's really nothing near line 29 in that file that would make it die. 
2.0.2b1 has
been run through SWIG on Linux/OS X/Windows on versions up to 1.3.39 (and I just
tested with 1.3.40 for Windows) with no issue.

Try commenting out the %include "Box2D/Box2D_printing.i" in Box2D/Box2D.i line 
61 or
thereabouts, and see if it works then. Or try using an older SWIG version.

Original comment by sir...@gmail.com on 7 Jan 2010 at 8:59

[GoogleCodeExporter]

The files are clean unziped from the source:
This is where it complains.

%extend b2AABB {
 %pythoncode %{
 def __repr__(self):
  return """b2AABB(
    lowerBound = %s,
    upperBound = %s,
    IsValid()  = %s)"""% tuple(str(a) for a in\
   (self.lowerBound,self.upperBound,self.IsValid()))
 %}
}

if I comment out the line in Box2D/Box2D.i then there is a error on the
Box2D_pickling.i :

Using setuptools.
running build
running build_py
copying ./__init__.py -> build/lib.macosx-10.6-i386-2.6/Box2D
running build_ext
building 'Box2D._Box2D' extension
swigging Box2D/Box2D.i to Box2D/Box2D_wrap.cpp
swig -python -c++ -IBox2D -O -includeall -ignoremissing -w201 -outdir . -o
Box2D/Box2D_wrap.cpp Box2D/Box2D.i
Box2D/Box2D_pickling.i:539: Error: Syntax error in input(1).
error: command 'swig' failed with exit status 1

and once again this is the last line of the first code block.

I tried with swig 1.3.39 and with the swig that come with mac os snowleopard( 
swig
1.3.31) it also fails with the same error.

Original comment by jc.lo...@gmail.com on 8 Jan 2010 at 10:19

[GoogleCodeExporter]

there was a mistake i my last comment:
the swig (1.3.31) that comes with snow leopard don't give that error ... but 
then
there are lots of cpp errors:

Using setuptools.
running build
running build_py
copying ./__init__.py -> build/lib.macosx-10.6-i386-2.6/Box2D
running build_ext
building 'Box2D._Box2D' extension
swigging Box2D/Box2D.i to Box2D/Box2D_wrap.cpp
swig -python -c++ -IBox2D -O -includeall -ignoremissing -w201 -outdir . -o
Box2D/Box2D_wrap.cpp Box2D/Box2D.i
creating build/temp.macosx-10.6-i386-2.6
creating build/temp.macosx-10.6-i386-2.6/Box2D
creating build/temp.macosx-10.6-i386-2.6/Box2D/Dynamics
creating build/temp.macosx-10.6-i386-2.6/Box2D/Dynamics/Contacts
creating build/temp.macosx-10.6-i386-2.6/Box2D/Dynamics/Controllers
creating build/temp.macosx-10.6-i386-2.6/Box2D/Dynamics/Joints
creating build/temp.macosx-10.6-i386-2.6/Box2D/Common
creating build/temp.macosx-10.6-i386-2.6/Box2D/Collision
creating build/temp.macosx-10.6-i386-2.6/Box2D/Collision/Shapes
/usr/bin/gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv 
-O3
-Wall -Wstrict-prototypes
-I/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 
-c
Box2D/Box2D_wrap.cpp -o build/temp.macosx-10.6-i386-2.6/Box2D/Box2D_wrap.o -I.
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC 
but
not for C++
Box2D/Box2D_wrap.cpp: In function ‘void SWIG_Python_AddErrorMsg(const 
char*)’:
Box2D/Box2D_wrap.cpp:871: warning: format not a string literal and no format 
arguments
 ... the list goes on ...
error: command '/usr/bin/gcc-4.2' failed with exit status 1

Original comment by jc.lo...@gmail.com on 8 Jan 2010 at 10:53

[GoogleCodeExporter]

Is there something with "%}" on Snow Leopard that I'm unaware of? It appears 
that's
where it's failing in both files, yet that syntax has not changed in SWIG 
1.3.x. It
also doesn't appear anyone has opened any related bug reports on the SWIG site.

Using the old SWIG version, you pasted just the warnings and not the actual 
error
that made it die. Would you please post the errors? Or even throw the whole 
output to
some pastebin-like site.

Original comment by sir...@gmail.com on 8 Jan 2010 at 12:56

[GoogleCodeExporter]

Just tested SWIG 1.3.40 on Linux, Python 2.6.2, i686 with no issues.

Original comment by sir...@gmail.com on 8 Jan 2010 at 2:40

[GoogleCodeExporter]

sorry for the delay. the output is on the attached file.

Original comment by jc.lo...@gmail.com on 9 Jan 2010 at 5:19

Attachments:

• error_log.txt

[GoogleCodeExporter]

Thanks for the log. Believe it or not, amidst all those ugly warnings (which 
are not
present on any other platform that I've seen), this is an already fixed bug. You
didn't mention it, but your platform is 64-bit, so the __hash__ casts to 
(int32) are
causing the errors.

If you update the individual files found in this SVN version:
http://code.google.com/p/pybox2d/source/detail?r=184 r184
And recompile, with the exception of a couple additional accessors, you'll have 
an
identical copy of 2.0.2b1. If you don't care about having perfect 2.0.2b1
compatibility, you might well be advised to just grab the most recent SVN 
version of
the trunk and give it a shot. 

I'm still a bit worried about the SWIG 1.3.40 errors. I will have to see if a 
friend
with Snow Leopard will let me install it on their machine to try it out. I'll 
leave
this issue open until then.

Original comment by sir...@gmail.com on 9 Jan 2010 at 5:39

• Changed state: Accepted

[GoogleCodeExporter]

Tested on Snow Leopard / SWIG 1.3.40 over the weekend with no errors. Perhaps 
the
user's SWIG install was invalid? In any case, unless this pops up more often 
I'll tag
it fixed for now.

Original comment by sir...@gmail.com on 11 Jan 2010 at 2:36

• Changed state: Duplicate

[GoogleCodeExporter]

With pyBox-trunk and swig 1.3.30 I manage to finish building pyBox2D with these 
warnings:

Box2D/Box2D_wrap.cpp: In function ‘void SWIG_Python_AddErrorMsg(const 
char*)’:
Box2D/Box2D_wrap.cpp:871: warning: format not a string literal and no format 
arguments
Box2D/Box2D_wrap.cpp: In function ‘PyObject* 
_wrap_b2Vec2_add_vector(PyObject*,
PyObject*)’:
Box2D/Box2D_wrap.cpp:5899: warning: format ‘%d’ expects type ‘int’, but 
argument 3
has type ‘Py_ssize_t’
... (more that look similar)

and with any other version of swig build in my machine it fails with the error 
of the
original post.

How did you tested with snowleopard? which version of Xcode/compiler did you 
build swig?

I'm using xcode 3.2.1 64bits

Original comment by jc.lo...@gmail.com on 12 Jan 2010 at 1:22

[GoogleCodeExporter]

Those warnings are fine, they appear to be just a SWIG issue on Xcode g++. I 
followed
the steps in the installation guide as had been written before (after replacing 
the
files to allow for 64-bit support).

The warning-ridden output that you just pasted was the same for me on a fairly 
new
installation of Snow Leopard 10.6 (.2 I believe), with Xcode 3.2.1 64-bit and 
SWIG
1.3.40 (built from source). It imported properly and hello.py worked, but I 
didn't
install pygame to check beyond that.

Original comment by sir...@gmail.com on 12 Jan 2010 at 2:29

[GoogleCodeExporter]

I'm getting jc.lopes original issue. I'm using OS 10.6.5, 64-bit, xcode 3.2.4, 
swig 2.0.1 (MacPorts), with files replaced from the SVN. any progress getting 
this to work with up-to-date versions?

Original comment by brian.ho...@gmail.com on 14 Dec 2010 at 4:25

[GoogleCodeExporter]

Same issue here on OS 10.6.5, xcode, and macports. Change in the files did 
nothing to help the situation, and dumping the output to see what happens gives 
me nothing.

No issue on Ubuntu or Debian. I don't have enough of a C++ background to really 
dig in to the issue.

Original comment by jbeis...@gmail.com on 31 Jan 2011 at 5:41