From: Pawel T. <pto...@me...> - 2014-11-18 18:05:14
|
Hi group, W dniu 29.07.2012 11:10, Michel Dupront pisze: > > Hello, > I am using swig2.0 on an ubuntu pangolin platform > with python2.7 and gcc-4.6. > > When I do: > %import "std_vector.i" > namespace{ > %template(vecd) vector<double>; > } > > I have the following error: > 'ptrdiff_t' does not name a type > > I can make it work adding before the > previous piece of code: > typedef std::ptrdiff_t ptrdiff_t; > > But then I get another error: > foo_wrap.cxx: In function ‘std::vector<unsigned int, > std::allocator<unsigned int> >* > std_vector_Sl_uint_Sg____getitem____SWIG_0(std::vector<unsigned int, > std::allocator<unsigned int> >*, PySliceObject*)’: > foo_wrap.cxx:4562:48: erreur: ‘SWIGPY_SLICE_ARG’ was not declared in > this scope > foo_wrap.cxx: In function ‘void > std_vector_Sl_uint_Sg____setitem____SWIG_0(std::vector<unsigned int, > std::allocator<unsigned int> >*, PySliceObject*, const > std::vector<unsigned int, std::allocator<unsigned int> >&)’: > foo_wrap.cxx:4571:48: erreur: ‘SWIGPY_SLICE_ARG’ was not declared in > this scope > foo_wrap.cxx: In function ‘void > std_vector_Sl_uint_Sg____setitem____SWIG_1(std::vector<unsigned int, > std::allocator<unsigned int> >*, PySliceObject*)’: > foo_wrap.cxx:4580:48: erreur: ‘SWIGPY_SLICE_ARG’ was not declared in > this scope > foo_wrap.cxx: In function ‘void > std_vector_Sl_uint_Sg____delitem____SWIG_1(std::vector<unsigned int, > std::allocator<unsigned int> >*, PySliceObject*)’: > foo_wrap.cxx:4589:48: erreur: ‘SWIGPY_SLICE_ARG’ was not declared in > this scope > > Does somebody know how to proceef from here ? > Thanks in advance > I have this problem too. I managed to reproduce the problem wit a simple example. Please correct me if I'm wrong, but it looks like a bug in swig library. The example consists of three files - othermod.i, testmod.i and compile, as follows: <code> // othermod.i %module othermod %include <std_vector.i> </code> <code> // testmod.i %module testmod %import <othermod.i> %include <std_vector.i> %{ #include <vector> %} %template(ints) std::vector<int>; </code> <code> #! /bin/sh swig -o testmod_wrap.cc -I. -I/usr/include -c++ -enumclass -python -builtin testmod.i g++ -o testmod_wrap.os -c -ansi -std=c++11 -Werror -Wall -Wextra -pedantic -Wno-maybe-uninitialized -Wno-unused-parameter -Wno-unused-label -Wno-deprecated-declarations -Wno-pedantic -g -O2 -fPIC -I. -I/usr/include/python2.7 testmod_wrap.cc g++ -o _testmod.so -Wl,-rpath-link=. -shared testmod_wrap.os -L. </code> When compiling, I see the following errors: ptomulik@tea:$ ./compile testmod_wrap.cc: In function ‘std::vector<int, std::allocator<int> >* std_vector_Sl_int_Sg____getitem____SWIG_0(std::vector<int, std::allocator<int> >*, PySliceObject*)’: testmod_wrap.cc:5065:48: error: ‘SWIGPY_SLICE_ARG’ was not declared in this scope PySlice_GetIndices(SWIGPY_SLICE_ARG(slice), (Py_ssize_t)self->size(), &i, &j, &step); ^ testmod_wrap.cc: In function ‘void std_vector_Sl_int_Sg____setitem____SWIG_0(std::vector<int, std::allocator<int> >*, PySliceObject*, const std::vector<int, std::allocator<int> >&)’: testmod_wrap.cc:5076:48: error: ‘SWIGPY_SLICE_ARG’ was not declared in this scope PySlice_GetIndices(SWIGPY_SLICE_ARG(slice), (Py_ssize_t)self->size(), &i, &j, &step); ^ testmod_wrap.cc: In function ‘void std_vector_Sl_int_Sg____setitem____SWIG_1(std::vector<int, std::allocator<int> >*, PySliceObject*)’: testmod_wrap.cc:5087:48: error: ‘SWIGPY_SLICE_ARG’ was not declared in this scope PySlice_GetIndices(SWIGPY_SLICE_ARG(slice), (Py_ssize_t)self->size(), &i, &j, &step); ^ testmod_wrap.cc: In function ‘void std_vector_Sl_int_Sg____delitem____SWIG_1(std::vector<int, std::allocator<int> >*, PySliceObject*)’: testmod_wrap.cc:5098:48: error: ‘SWIGPY_SLICE_ARG’ was not declared in this scope PySlice_GetIndices(SWIGPY_SLICE_ARG(slice), (Py_ssize_t)self->size(), &i, &j, &step); The problem disappears when I comment-out the %import <othermod.i> line, or change the order of includes to: <code> %include <std_vector.i> %import <othermod.i> </code> Anyone else can reproduce this? Any ideas of how it could be fixed? I think, the way the modules are included in the above example is a quite common patter (in theory I shouldn't worry about what the <othermod.i> %includes), the things should simply work. Best regards! -- Paweł Tomulik |