Re: [Bug-gsl] gsl 2.1 test failures

[sisyphus1]

Hi,

It might well be that loosening the tolerances will allow the tests to pass.

But there would still remain (re Windows, at least) the puzzle that, given 
that the present tolerances are fine for 32-bit gcc-4.9.2, how come they're 
not for good enough for 32-bit gcc-4.8.2 ?
What changed between  4.8.2 and 4.9.2 that should necessitate a loosening of 
the tolerances for the former ?

Oddly, with my Windows builds I find that if I add the configure arg 
'CFLAGS=-D__USE_MINGW_ANSI_STDIO' to the 32-bit gcc-4.8.2 build then the 
problem vanishes, and all tests succeed.
But I really didn't expect that adding *that* configure arg would have such 
an effect ... and I'm a bit nonplussed as to why it *does* have that effect.

__USE_MINGW_ANSI_STDIO is a symbol I usually define (to a true value) to 
ensure that an  ANSI C99 compatible implementation of printf() is obtained, 
and I don't really know much about the way it works or what else it does.

Any insights into that ? ... or why it's inclusion should fix the failures 
with the multifit tests ?

As regards the OP's failures on Fedora, I guess this prompts me to ask 
whether the compiler in use there is ANSI C99-compliant ?

Is there anything in multifit that assumes ANSI C99-compliance ?

Cheers,
Rob


-----Original Message----- 
From: Patrick Alken
Sent: Friday, November 13, 2015 9:49 AM
To: address@hidden ; address@hidden
Subject: Re: [Bug-gsl] gsl 2.1 test failures

> I will try to figure out how to cross-compile gsl in 32bit mode on my
> machine, it might take a few days for me to resolve this. In the
> mean-time, I don't think there is any problem in using GSL in 32 bit, just
> that the test tolerances are too tight for 32 bit to pass the tests.