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
