The fulvia failure is due to an incorrectly set LD_LIBRARY_PATH on the
machine. It has nothing to do with MPIR being broken.

Is that the reason for the red core2/Solaris in the test matrix?

Bill.

On 9 June 2010 01:29, Bill Hart <[email protected]> wrote:
> On 9 June 2010 01:23, Minh Nguyen <[email protected]> wrote:
>> Hi Bill,
>>
>> On Wed, Jun 9, 2010 at 10:05 AM, Bill Hart <[email protected]> 
>> wrote:
>>> Thanks very much Minh for all the hard work in doing the release
>>> management for MPIR 2.1.0 !!
>>>
>>> By the way, we can remove this from the list of known problems on the
>>> MPIR website:
>>>
>>> * MPIR normalises its extended GCD differently to GMP 5.0.1. - trac #293
>>
>> Done.
>>
>>
>>> I'm also confused by the reds in the testing matrix. Are these actual
>>> MPIR failures or are they merely due to broken compilers, incorrectly
>>> set up machines or invalid ABIs in the test script?
>>
>> What color do we use if:
>>
>> * the build went OK with just ./configure && make; and
>> * the test suite has a failure?
>
> That's a red, unless the compiler is known to be broken. The only
> broken compiler that I know of is gcc 4.3.2 on 64 bit machines or gcc
> 4.5.0 on ia64 (though we safely work around the latter). (There are
> some exceptions to this, but they are noted in the known problems
> section of the website - e.g. some C standard libraries have bugs.)
>
> That's also assuming the test suite actually failed with FAIL, rather
> than a build failure, which may indicate a faulty setup on the
> machine.
>
> It's better to talk about specific examples. Which ones do you think
> we should give a red and why? Remember this matrix is supposed to
> indicate which kinds of arch/OS combinations a user should expect MPIR
> to work out of the box on (assuming their compiler works and their
> machine is set up correctly).
>
>>
>>
>>> I would simply list them as white "unavailable" if we have no passed
>>> build reports for a given arch/OS combination. I don't think we should
>>> be reporting failures with MPIR that have nothing to do with MPIR. Of
>>> course if they are genuine failures, then we should have tickets for
>>> them and notes in the "known problems" section of the website.
>>
>> Noted.
>>
>> --
>> Regards
>> Minh Van Nguyen
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mpir-devel?hl=en.

Reply via email to