Thanks for replying, Martin.
I got my colleague (Nils) to run exactly the gcc call you described in
your post (see below for what he ran) but it only returns the
following:
/home/nwagner/svn/PyDSTool/PyDSTool/tests/dopri853_temp/dop853_HHnet_vf_wrap.c:124:20:
error: Python.h: Datei oder Verzeichnis nicht gefunden
/home/nwagner/svn/PyDSTool/PyDSTool/tests/dopri853_temp/dop853_HHnet_vf_wrap.c:2495:4:
error: #error This python version requires swigto be run with the
'-classic' option
In file included from
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h:61,
from
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include/numpy/arrayobject.h:14,
from
/home/nwagner/local/lib64/python2.6/site-packages/numpy/numarray/numpy/libnumarray.h:7,
from
/home/nwagner/svn/PyDSTool/PyDSTool/tests/dopri853_temp/dop853_HHnet_vf_wrap.c:2758:
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_common.h:71:2:
error: #error Must use Python with unicode enabled.
The command was
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC
-I/data/home/nwagner/local/lib/python2.5/site-packages/numpy/core/include
-I/data/home/nwagner/local/lib/python2.5/site-packages/numpy/numarray
-I/data/home/nwagner/svn/PyDSTool/PyDSTool/tests
-I/data/home/nwagner/svn/PyDSTool/PyDSTool/integrator
-I/data/home/nwagner/svn/PyDSTool/PyDSTool/tests/dopri853_temp
-I/data/home/nwagner/local/include/python2.5 -E -dD
/data/home/nwagner/svn/PyDSTool/PyDSTool/tests/dopri853_temp/dop853_HHnet_vf_wrap.c
-w -m32 -D__DOPRI__
Maybe Nils can pick up the thread from here.
Thanks,
Rob
On Sun, Mar 22, 2009 at 2:36 AM, Martin v. Löwis mar...@v.loewis.de wrote:
/data/home/nwagner/local/lib/python2.5/pyport.h:734:2: #error
LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?).
Can anyone offer any advice as to what I might be missing or
misunderstanding?
You need to understand where the error comes from:
1. what is the *actual* value of SIZEOF_LONG (it should be 4)?
2. what is the actual value of LONG_BIT, and where does it come
from? (it should be 32)
To understand that better, I recommend to edit the command line
of gcc in the following way (assuming you use gcc 4.x):
1. replace -c with -E -dD
2. remove the -o file option
This will generate preprocessor output to stdout, which you then
need to search for SIZEOF_LONG and LONG_BIT. Searching back for
# number lines will tell you where the definition was made.
If that doesn't make it clear what the problem is, post your
findings here.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
