Hi pylucene-dev, If I use gcc-4.3 to build the jcc included with pylucene 2.4.0-1 (downloaded from the official website), it fails on JArray.cpp with this message:
jcc/sources/JArray.cpp:621: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:627: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:633: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:723: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:730: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:801: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:852: error: explicit template specialization cannot have a storage class jcc/sources/JArray.cpp:903: error: explicit template specialization cannot have a storage class For reference, I'm using this gcc: Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) The gcc-4.3 docs say that the c++ gurus say that you can't specify a storage class when explicitly specializing a template: http://gcc.gnu.org/gcc-4.3/porting_to.html Explicit template specialization cannot have a storage class Specializations of templates cannot explicitly specify a storage class, and have the same storage as the primary template. This is a change from previous behavior, based on the feedback and commentary as part of the ISO C++ Core Defect Report 605. I took their advice and removed "static" from those specializations: --- oldJArray.cpp 2008-10-11 19:29:03.000000000 -0400 +++ JArray.cpp 2008-11-10 18:50:34.000000000 -0500 @@ -615,25 +615,25 @@ }; template<> -static PyObject *get(_t_jobjectarray<jobject> *self, int n) +PyObject *get(_t_jobjectarray<jobject> *self, int n) { return self->array.get(n, self->wrapfn); } template<> -static PyObject *toSequence(_t_jobjectarray<jobject> *self) +PyObject *toSequence(_t_jobjectarray<jobject> *self) { return self->array.toSequence(self->wrapfn); } template<> -static PyObject *toSequence(_t_jobjectarray<jobject> *self, int lo, int hi) +PyObject *toSequence(_t_jobjectarray<jobject> *self, int lo, int hi) { return self->array.toSequence(lo, hi, self->wrapfn); } template<> -static int init< jobject,_t_jobjectarray<jobject> >(_t_jobjectarray<jobject> *self, PyObject *args, PyObject *kwds) +int init< jobject,_t_jobjectarray<jobject> >(_t_jobjectarray<jobject> *self, PyObject *args, PyObject *kwds) { PyObject *obj, *clsObj = NULL; PyObject *(*wrapfn)(const jobject &) = NULL; @@ -723,14 +723,14 @@ } template<> -static jclass initializeClass<jobject>(void) +jclass initializeClass<jobject>(void) { jclass cls = env->findClass("java/lang/Object"); return env->get_vm_env()->GetObjectClass(JArray<jobject>(cls, 0).this$); } template<> -static PyObject *cast_<jobject>(PyTypeObject *type, +PyObject *cast_<jobject>(PyTypeObject *type, PyObject *args, PyObject *kwds) { PyObject *arg, *clsArg = NULL; @@ -801,7 +801,7 @@ } template<> -static PyObject *instance_<jobject>(PyTypeObject *type, +PyObject *instance_<jobject>(PyTypeObject *type, PyObject *args, PyObject *kwds) { PyObject *arg, *clsArg = NULL; @@ -852,7 +852,7 @@ } template<> -static PyObject *assignable_<jobject>(PyTypeObject *type, +PyObject *assignable_<jobject>(PyTypeObject *type, PyObject *args, PyObject *kwds) { PyObject *arg, *clsArg = NULL; This seems to work. I'm curious: is dumping the 'static' storage class likely to break anything? best, Joe P.S.: I usually set my umask to 0027. If I build jcc with python setup.py build; sudo python setup.py install, my installed jcc dir is not world-readable. I think there might be a perms-setting step missing in the setup script. (If I chmod o+r everything before the build and set the building user's umask to 0022, the installed files have the correct perms.) _______________________________________________ pylucene-dev mailing list pylucene-dev@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
