search for: chert_check

Report by Eric Lindblad 30-09-2015 http://www.ericlindblad.blogspot.com The xapian-core-1.2.21 'ambiguous overload' error on the files /backends/brass/brass_check.cc and /backends/chert/chert_check.cc appear to be resultant of a bug reported in gcc-3.3.4, which was fixed for 3.4.2 [Sept. 6, 2004] and 3.5. Bug 16854 - streams missing "long long" specializations on Tru64 https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=16854 Running 'g++ foo.cc' (from the abo...

...entest resolverelativepath1 ... ok PASS: unittest The disabling of brass and chert backends (the same mailing-list member noting that compile of 1.2.x with just flint support being of somewhat limited use) was due to an earlier encountered 'ambiguous overload' error on brass_check.cc & chert_check.cc. The above test was performed on a machine without network access. With the define for 'htons' on Interix located in /dev/fs/C/SFU/usr/include/arpa/inet.h the addition of '#include <arpa/inet.h>' in xapian-core-1.2.21/net/tcplclient.cc allowed for remote's compile on...

...itten in the text box here: http://trac.xapian.org/ticket/625 noting the cause of that error was their configure argument as disabling the remote backend. It appears that Interix 3.5's gcc-3.3 was compiled without '--enable-long-long', which likely was the cause of the brass_check.cc/chert_check.cc compile errors. Compiling a new gcc-3.3 with '--enable-long-long' for Interix 3.5 should enable compile of those 2 backend files, but if xapian 1.1.x or 1.2.x series were to be compiled the remote backend (requirement) would need to also be compiled, other- wise, flint and quartz (with...

...dblad.blogspot.com cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9885 modifications allowing for brass and chert to compile on SFU Interix 3.5 (modified) [code change not performance critical] /xapian-core-1.2.21/backends/brass/brass_check.cc /xapian-core-1.2.21/backends/chert/chert_check.cc #include <climits> + +#include "str.h" out << "base" << (char)B.base_letter << " blocksize=" << B.block_size / 1024 << "K" - " items=" << B.item_count + << " items="...

We've had some catastrophic filesystem failures that have left us with corrupted databases with empty files and no backup for about 15TB of our data. Recreating the 15TB from source data backups is possible but will take a very very long time. I'm hoping that, given all of the .DB files are still intact, there my be some way to extract their contents and rebuild the other tables. This

...nds/.libs/dbfactory_remote.o backends/.libs/contiguousalldocspostlist.o backends/.libs/flint_lock.o backends/chert/.libs/chert_alldocsmodifiedpostlist.o backends/chert/.libs/chert_alldocspostlist.o backends/chert/.libs/chert_alltermslist.o backends/chert/.libs/chert_btreebase.o backends/chert/.libs/chert_check.o backends/chert/.libs/chert_compact.o backends/chert/.libs/chert_cursor.o backends/chert/.libs/chert_database.o backends/chert/.libs/chert_databasereplicator.o backends/chert/.libs/chert_dbcheck.o backends/chert/.libs/chert_dbstats.o backends/chert/.libs/chert_document.o backends/chert/.libs/chert...