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.