bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Failed test on Solaris 8 Sparc


From: Simon Josefsson
Subject: Re: Failed test on Solaris 8 Sparc
Date: Mon, 21 Nov 2011 12:43:10 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)

Dagobert Michelsen <address@hidden> writes:

> Hi Simon,
>
> Am 21.04.2010 um 08:36 schrieb Simon Josefsson:
>> Dagobert Michelsen <address@hidden> writes:
>>> Am 31.03.2009 um 12:23 schrieb Simon Josefsson:
>>>> Dagobert Michelsen <address@hidden> writes:
>>>>> I am getting a test failure on Solaris 8 Sparc w/Sun Studio 11:
>>>> 
>>>> Hi! Thanks for the report.  The problem is actually in a self-test
>>>> from
>>>> gnulib.  Your GNU SASL library build should still be fine, if this is
>>>> the only problem.  poll is only used by the 'gsasl' tool, and it most
>>>> likely doesn't require the behaviour tested for by the gnulib self-
>>>> test.
>>>> So a 'make install' should be safe.
>>>> 
>>>>>> Unconnected socket test... passed
>>>>>> Connected sockets test... failed (expecting POLLHUP after shutdown)
>>>>>> General socket test with fork... failed (expecting POLLHUP after
>>>>>> shutdown)
>>>>>> FAIL: test-poll
>>>> 
>>>> Does anyone recognize this problem?
>>>> 
>>>> If there is no simple solution, I'll disable the self-test in gsasl.
>>> 
>>> Any news on this? I just tested gsasl 1.4.4 on Solaris 9 w/Sun Studio
>>> 12 and the error still occurs.
>> 
>> The error is a likely a problem in the gnulib self-tests.  If that
>> problem isn't resolved in response to your e-mail within a few weeks,
>> please ping me again and I'll disable the self test since in GNU SASL.
>> 
>> Meanwhile you can patch your local copy to not run this particular test,
>> I believe your GNU SASL installation should be fine if this is the only
>> self test failing.
>
> The error is still present in 1.6.1, what can we do about that?
> Talking to the gnulib maintainers?

I have disabled the test-poll self test on the gsasl 1.6.x branch which
is a maintenance branch.  For the 1.7.x development branch and
subsequent stable 1.8.x branch we'll use the latest gnulib and hopefully
this problem has been resolved -- I'll confirm this once I have pushed
1.6.2 out the door.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]