On Nov 10, 2008, at 21:25, Joseph Barillari <[EMAIL PROTECTED]> wrote:
> 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? If it works for you and on the other, older, earlier compilers, then it's probably good. I'm not near a computer this week to try this out but I should know more next week. Thanks for reporting this and for the fix. > 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.) That might be an issue with distutils or setuptools which implement 'install'. Check with them. If there is a workaround, send in a patch. Andi.. > > > _______________________________________________ > pylucene-dev mailing list > pylucene-dev@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/pylucene-dev _______________________________________________ pylucene-dev mailing list pylucene-dev@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
