I do confirm this error. Our cluster uses CentOS 6 as well and gives almost _exactly_ the same values:

$ uname -r
2.6.32-642.6.1.el6.x86_64
$ ldd --version
ldd (GNU libc) 2.12
$ gcc --version
gcc (GCC) 5.5.0

FAIL: gsl_sf_bessel_j2_e(1048576.0, &r) [168]
  expected: -3.1518539455252412e-07
  obtained: -3.1518539455252539e-07 +/- 2.7994086564622246e-22 (rel=8.88178e-16)
  fracdiff: 2.0155588470164931e-15
 tolerance: 4.5474735088646412e-13
  value/expected not consistent within reported error
  -3.151853945525253879e-07  2.799408656462224591e-22
FAIL: Bessel Functions [407]

Updating gsl to version 2.5 fixes this problem.

At the same time I have no problems with my desktop:

$ uname -r
4.17.3-200.fc28.x86_64
$ ldd --version
ldd (GNU libc) 2.27
$ gcc --version
gcc (GCC) 8.1.1 20180712 (Red Hat 8.1.1-5)

I also would like to report a bug here since it's related to Bessel functions. According to this an example from the documentation gives incorrect answers.

# include <stdio.h>
# include <gsl/gsl_sf_bessel.h>
int main (void)
{
double x = 5.0;
double y = gsl_sf_bessel_j0 (x);
printf ("JO(%g) =  %.18e\n", x , y);
return(0);
}

What you get: JO(5) =  -1.917848549326277019e-01.
What you expect (see documentation): JO(5) =  -1.775967713143382920e-01.
When I replace gsl_sf_bessel_j0 with gsl_sf_bessel_J0 I get JO(5) =  -1.775967713143382642e-01 which is close to the desired output.

from eshell =at= ucsc =dot= edu

subject: GSL 2.4 make check failing on Rocks cluster running CentOS 6.9

note: it looks like the error term (r) is causing the failure, not the computed j2 value itself

---

Thanks much for the quick reply!  I incremented the tolerance value, but it
is still failing even at TEST_TOL6:

======================================
   gsl 2.4: specfunc/test-suite.log
======================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test
==========

FAIL: gsl_sf_bessel_j2_e(1048576.0, &r) [168]
  expected: -3.1518539455252412e-07
  obtained: -3.1518539455252539e-07 ± 2.7994086564622246e-22
(rel=8.88178e-16)
  fracdiff: 2.0155588470164931e-15
 tolerance: 2.3283064365386963e-10
  value/expected not consistent within reported error
  -3.151853945525253879e-07  2.799408656462224591e-22
FAIL: Bessel Functions [407]

On Thu, Jan 18, 2018 at 3:01 PM, Patrick Alken <alken@colorado.edu> wrote:

> Hello,
>
>   It looks like its calculating the value correctly, but the test
> tolerance needs to be relaxed slightly. Can you locate this line in
> specfun/test_bessel.c:
>
>  186   TEST_SF(s,  gsl_sf_bessel_j2_e, (1048576.0, &r),
> -3.1518539455252413111e-07, TEST_TOL3, GSL_SUCCESS);
>
> and change the TEST_TOL3 to TEST_TOL4, and let me know if the test passes?
> If not try TEST_TOL5 and then TEST_TOL6, and tell me which one allows the
> test to pass.
>
> Thanks,
> Patrick
>
>
> On 01/18/2018 03:56 PM, Eric Shell wrote:
>
>> Hello,
>>
>> I'm trying to install GSL 2.4 on a Rocks cluster running CentOS 6.9, gcc
>> version 4.4.7.  I am running configure with just a --prefix argument.
>> make
>> succeeds without errors, but make check is failing on the specfunc test.
>> Here are the contents of the log file:
>>
>> ------------------------------------------------------------
>> --------------------
>>
>> ======================================
>>     gsl 2.4: specfunc/test-suite.log
>> ======================================
>>
>> # TOTAL: 1
>> # PASS:  0
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
>>
>> .. contents:: :depth: 2
>>
>> FAIL: test
>> ==========
>>
>> FAIL: gsl_sf_bessel_j2_e(1048576.0, &r) [168]
>>    expected: -3.1518539455252412e-07
>>    obtained: -3.1518539455252539e-07 ± 2.7994086564622246e-22
>> (rel=8.88178e-16)
>>    fracdiff: 2.0155588470164931e-15
>>   tolerance: 4.5474735088646412e-13
>>    value/expected not consistent within reported error
>>    -3.151853945525253879e-07  2.799408656462224591e-22
>> FAIL: Bessel Functions [407]
>>
>> ------------------------------------------------------------
>> --------------------
>>
>> Is this a known issue?  How can I address the underlying issue?
>>
>> Thanks!
>>
>> - Eric
>>