search for: xapian_wrap

...ntering directory `/root/xapian/xapian-bindings-0.9.0/php4' if /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/php4 -I/usr/include/php4/main -I/usr/include/php4/Zend -I/usr/include/php4/TSRM -Wall -Wno-unused -Wno-uninitialized -g -O2 -I/usr/local/include -MT xapian_wrap.lo -MD -MP -MF ".deps/xapian_wrap.Tpo" -c -o xapian_wrap.lo xapian_wrap.cc; \ then mv -f ".deps/xapian_wrap.Tpo" ".deps/xapian_wrap.Plo"; else rm -f ".deps/xapian_wrap.Tpo"; exit 1; fi mkdir .libs g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/php4 -I/usr/i...

...ing all in python3 make[2]: Entering directory '/home/<me>/.local/share/virtualenvs/<venv>/src/xapian-bindings-1.4.7/python3' make all-am make[3]: Entering directory '/home/<me>/.local/share/virtualenvs/<venv>/src/xapian-bindings-1.4.7/python3' depbase=`echo xapian_wrap.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/python3.6m -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fvisibility=hidden -I/home/<me>/.local/share/virtualenvs/<venv>/incl...

...' make all-am make[3]: ?????? `/home/jack/SE/xapian-bindings-1.2.5/python' /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/python2.6 -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fvisibility=hidden -I/usr/local/include -g -O2 -MT xapian_wrap.lo -MD -MP -MF .deps/xapian_wrap.Tpo -c -o xapian_wrap.lo `test -f 'modern/xapian_wrap.cc' || echo './'`modern/xapian_wrap.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/python2.6 -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fvisibility=hidden -I/usr...

...ll-recursive Making all in docs Making all in examples if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/python2.3 -Wall -Wno-unused -Wno-uninitialized -g -O2 -I/usr/local/src/xapian-core-0.9.2/include -I/usr/local/src/xapian-core-0.9.2/extra -MT xapian_wrap.lo -MD -MP -MF ".deps/xapian_wrap.Tpo" -c -o xapian_wrap.lo `test -f 'modern/xapian_wrap.cc' || echo './'`modern/xapian_wrap.cc; then mv -f ".deps/xapian_wrap.Tpo" ".deps/xapian_wrap.Plo"; else rm -f ".deps/xapian_wrap.Tpo"; exit 1; fi mkdir...

With the new "stamp" rules for running SWIG, things don't seem to get rebuilt when I expect them to, e.g.: olly at ixion:~/svn/xapian/xapian-bindings/python $ make modern/xapian_wrap.cc make: Nothing to be done for `modern/xapian_wrap.cc'. olly at ixion:~/svn/xapian/xapian-bindings/python $ ls -l modern/xapian_wrap.cc ls: modern/xapian_wrap.cc: No such file or directory Problem being that the "stamp" file already exists. This used to work before though... Cheer...

I'm having a problem compiling the python 2.1 packages for release 0.9.1 - I get many errors along the lines of: ../../python/olde/xapian_wrap.cc: In function `PyObject* PySwigObject_repr(PySwigObject*)': ../../python/olde/xapian_wrap.cc:664: error: `PyString_FromFormat' undeclared (first use this function) On further investigation, the copies of xapian_wrap.cc in the olde and modern subdirectories of the python binding sou...

...ll-recursive make[1]: Entering directory `/root/compile/xapian/xapian-bindings-0.8.3' Making all in tcl8 make[2]: Entering directory `/root/compile/xapian/xapian-bindings-0.8.3/tcl8' make all-am make[3]: Entering directory `/root/compile/xapian/xapian-bindings-0.8.3/tcl8' source='xapian_wrap.cc' object='xapian_wrap.lo' libtool=yes \ depfile='.deps/xapian_wrap.Plo' tmpdepfile='.deps/xapian_wrap.TPlo' \ depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/tcl8.3 -Wall -Wno-unused -Wno-uninitializ...

...de overrides for the documentation comments. */ %include "extracomments.i" Index: python/Makefile.am =================================================================== --- python/Makefile.am (revision 8794) +++ python/Makefile.am (working copy) @@ -9,7 +9,12 @@ BUILT_SOURCES = modern/xapian_wrap.cc modern/xapian_wrap.h modern/xapian.py -EXTRA_DIST = util.i extra.i extracomments.i except.i doccomments.i\ +if HAVE_DOCCOMMENTS_SOURCES +DOCCOMMENTS_I = doccomments.i +DOCCOMMENTS_I_FLAGS=-DDOCCOMMENTS_I_SOURCES +endif + +EXTRA_DIST = util.i extra.i extracomments.i except.i $(DOCCOMMENTS_I)\...

I've uploaded Xapian 1.2.6 (including Search::Xapian 1.2.6.0). As usual you can download from: http://xapian.org/download You can read an overview of the release here: http://trac.xapian.org/wiki/ReleaseOverview/1.2.6 The full lists of user-visible changes are linked to from there, and also from the "[news]" links on the download page. As always, if you encounter problems,

...iler getting killed. > Then "make" fails with: [...] > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/python3.6m -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fvisibility=hidden -I/home/<me>/.local/share/virtualenvs/<venv>/include -g -O2 -MT xapian_wrap.lo -MD -MP -MF .deps/xapian_wrap.Tpo -c xapian_wrap.cc -fPIC -DPIC -o .libs/xapian_wrap.o > g++: internal compiler error: Killed (program cc1plus) This seems to indicate the compiler received SIGKILL, which smells to me like the kernel's OOM (Out Of Memory) killer kicked in. The bindings...

...m using CygWin (the full version). Have already compiled the xapian-core, using a change found in gmane for the file safewindows.h In cygwin path usr/local/ have the xapian lib etc. For the binding the ./configure command passes ok. when the make starts I get the folowing : .... MANY ERRORS at xapian_wrap.cc ..... ..... /cygdrive/d/AutomaticTextAnalysis-1.3-rc1/xapian-bindings/python/modern/xapian_w rap.cc:1661: undefined reference to `_PyInt_AsLong' .libs/xapian_wrap.o: In function `swig_varlink_repr': /cygdrive/d/AutomaticTextAnalysis-1.3-rc1/xapian-bindings/python/modern/xapian_w rap.cc:2...

...ore following readme in ...\win32msvc, apitest doesn?t give errors now if i try to build: "...\ruby>nmake SWIGBUILD=1 Microsoft (R) Program Maintenance Utility, Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: "".\xapian_wrap.cc"" don't know how to make Stop." i?m pretty sure my SWIG-path is set correctly in config.mak; i couldn?t find any xapian_wrap.* file in the repository, i suppose those should be generated by SWIG? does someone know what i could do or try to get it working? any help would...

...SYS. I know, it's probably not your main platform, but someone might need it as I do, for whatever reason. The reason why it fails, I think, is that Xapian::Remote::open is probably not supported on Win32. When I realized it, I finally managed to exclude from the (provided) SWIG-generated xapian_wrap.cc the unsupported lines, and to "gently" raise an exception when remote_open() is called. Here is the patch for python/modern/xapian_wrap.cc: --- xapian_wrap.cc_ORIG Fri Mar 25 16:42:49 2005 +++ xapian_wrap.cc Fri Mar 25 17:53:18 2005 @@ -15350 +15350,2 @@ - +// remote_open should be...

...SYS. I know, it's probably not your main platform, but someone might need it as I do, for whatever reason. The reason why it fails, I think, is that Xapian::Remote::open is probably not supported on Win32. When I realized it, I finally managed to exclude from the (provided) SWIG-generated xapian_wrap.cc the unsupported lines, and to "gently" raise an exception when remote_open() is called. Here is the patch for python/modern/xapian_wrap.cc: --- xapian_wrap.cc_ORIG Fri Mar 25 16:42:49 2005 +++ xapian_wrap.cc Fri Mar 25 17:53:18 2005 @@ -15350 +15350,2 @@ - +// remote_open should be...

Carrying on this conversation: http://lists.tartarus.org/pipermail/xapian-discuss/2007-March/003513.html void TermGenerator::set_stopper(stopper) Stopper * stopper CODE: // FIXME: no corresponding SvREFCNT_dec(), but a leak seems better than // a SEGV! SvREFCNT_inc(ST(1)); THIS->set_stopper(stopper); It would be good to fix these FIXMEs. A class-level HASH could be

...y work around? I'd have a look at it myself but I don't really know where to start (and my C/C++ is very basic). Dave (gdb) bt #0 0x00000019 in ?? () #1 0xb766dccf in __wrap_delete_WritableDatabase (rsrc=0x80a27ec, type_name=0xb76e0d15 "_p_Xapian__WritableDatabase") at xapian_wrap.cc:13182 #2 0xb766f205 in _wrap_destroy_p_Xapian__WritableDatabase (rsrc=0x80a27ec) at xapian_wrap.cc:16836 #3 0xb7f8410d in list_entry_destructor () from /usr/lib/libphp_common.so.432 #4 0x080a27ec in ?? () #5 0x00000027 in ?? () #6 0xbfff6d70 in ?? () #7 0xb7fe6c80 in ?? () #8 0x080c8ba8...

A short note: this message comes as a public reply to a discussion about xapian-bindings, that is why it can look a little bit incomplete... however the problem for now was to modify the xapian-core distribution so that there are symbols #defined (or maybe #undefined) to reflect what backends were available in the library. As I said to Olly, I'm a complete newbie at Autotools (and SWIG), so

...ke[5]: Nothing to be done for `all'. make[5]: Nothing to be done for `all-am'. /bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -Wno-unused \ -Wno-uninitialized -g -O2 -I/usr/local/include -o _xapian.la \ -rpath /Library/Frameworks/Python.fr [cut] g++ -o .libs/_xapian.so -bundle .libs/xapian_wrap.o \ /usr/local/lib/libxapian.dylib /usr/bin/ld: Undefined symbols: _PyArg_ParseTuple _PyCFunction_Type _PyCObject_FromVoidPtr _PyCObject_Import _PyDict_GetItemString _PyDict_SetItemString _PyErr_Clear _PyErr_Fetch _PyErr_Format _PyErr_Occurred _PyErr_SetString _PyExc_...

...pears as "Xapian 1.0.1 bindings for PHP 5.2.2" Here is what I changed: - In win32/Makefile, target COPYMAKFILES, added: if exist $(XAPIAN_BINDINGS) copy version.rc $(XAPIAN_BINDINGS)\php - In win32/win32_bindings_php.mak: added version.res to LIB_XAPIAN_OBJS LIB_XAPIAN_OBJS= ".\xapian_wrap.obj" ".\version.res" added a rule to build version.res from version.rc: ".\version.res": version.rc $(RSC) /v \ /fo version.res \ /I "$(XAPIAN_CORE_REL_PHP)\include" \ /I "$(PHP_SRC_DIR)\main" \ /d PHP_MAJOR_VERSION=&...

Hi All Is there any reason why someone could not build a regular PHP extension (not using SWIG) for Xapian? Same as mnoGoSearch has. The extension itself would be released under the PHP license. Is there anything on either side of the pond that would prevent this from being legal? Alec