Dear Olly Betts,
same 32 bit
compiler version
hardware
OS
OS version
as here (where remotetcp_chert passed and skipped 3)
xapian-core-1.2.21.tar.xz
http://nurmi-labs.blogspot.com/2015/10/xapian.html
./apitest backend remoteprog_brass: All 225 tests passed, 3 skipped.
./apitest backend remotetcp_brass: All 225 tests passed, 3 skipped.
./apitest backend remoteprog_chert: All 225 tests passed, 3 skipped.
./apitest backend remotetcp_chert: All 225 tests passed, 3 skipped.
./apitest backend remoteprog_flint: All 219 tests passed, 2 skipped.
./apitest backend remotetcp_flint: All 219 tests passed, 2 skipped.
Sincerely,
Eric Lindblad
--------------------------------------------
On Thu, 12/8/16, Olly Betts <olly at survex.com> wrote:
Subject: Re: configure & make_check logs w/out '--disable-sse'
To: "Eric Lindblad" <geirfuglaps at yahoo.com>
Cc: xapian-discuss at lists.xapian.org
Date: Thursday, December 8, 2016, 10:45 PM
On Thu, Dec 08, 2016 at
09:25:01PM +0000, Eric Lindblad wrote:
>
System: Slackware Linux (version 14.0)
>
CPUs: Intel(R) Atom(TM) CPU N270 @1.60GHz
>
>
xapian-core-1.4.1.tar.xz
>
> http://nurmi-labs.blogspot.com/p/xapian-linux-sse.html
Looks like it's now just
failing all the remotetcp tests. The problem
seems to be that 127.0.0.1 fails to resolve.
Does the machine really not
even have
loopback networking?
I
guess the testsuite could detect that case and skip those
tests, though
it seems quite a lot of effort
for a very rare case.
Anyway, there's no actual problems with the
library shown there, just
with the
testharness.
Cheers,
Olly
On Thu, Dec 08, 2016 at 10:08:40PM +0000, Eric Lindblad wrote:> Dear Olly Betts, > > same 32 bit > > compiler version > hardware > OS > OS version > > as here (where remotetcp_chert passed and skipped 3) > > xapian-core-1.2.21.tar.xz > > http://nurmi-labs.blogspot.com/2015/10/xapian.htmlThat's over a year old - are you really running the exact same versions now as then?> ./apitest backend remoteprog_brass: All 225 tests passed, 3 skipped. > ./apitest backend remotetcp_brass: All 225 tests passed, 3 skipped. > ./apitest backend remoteprog_chert: All 225 tests passed, 3 skipped. > ./apitest backend remotetcp_chert: All 225 tests passed, 3 skipped. > ./apitest backend remoteprog_flint: All 219 tests passed, 2 skipped. > ./apitest backend remotetcp_flint: All 219 tests passed, 2 skipped.Skipped tests are fine - they just indicate things like a testcase isn't currently able to be run for a particular backend, or something needed to run the test isn't present. Only failed tests indicate a problem. A notable change to the networking code between 1.2 and 1.4 was that we switched to using getaddrinfo() to resolve names. But that ought to be able to handle a string with an IP address, as it does on Linux, etc. For the server we use: hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG | AI_NUMERICSERV; And for the client: hints.ai_flags = AI_ADDRCONFIG | AI_NUMERICSERV; The switch to getaddrinfo() was a first step towards IPv6 support, but also replaces use of an obsolete, non-thread-safe API with a thread-safe alternative API which we can reasonably expect all platforms to support by now (getaddrinfo() is the standardised way to support IPv6, and lack of IPv6 would be a gaping hole in any OS at this point in time, unless perhaps it has a limited field of intended use). IPv6 is currently slated for 1.5.0, but could be backported to 1.4.x is there's actually demand (so far nobody has actually asked about it that I can recall): https://trac.xapian.org/ticket/374 Cheers, Olly
On Tue, Dec 13, 2016 at 03:22:50AM +0000, Olly Betts wrote:> On Thu, Dec 08, 2016 at 10:08:40PM +0000, Eric Lindblad wrote: > > same 32 bit > > > > compiler version > > hardware > > OS > > OS version > > > > as here (where remotetcp_chert passed and skipped 3) > > > > xapian-core-1.2.21.tar.xz > > > > http://nurmi-labs.blogspot.com/2015/10/xapian.html > > That's over a year old - are you really running the exact same > versions now as then?Ah, I see you built 1.2.24 too (starting a new thread for every message makes it harder to keep up). Cheers, Olly