On 04/15/2014 05:18 PM, Assaf Gordon wrote: > + dnl On some systems (OpenBSD5.4) the system's native expl() is buggy: > + dnl it returns 'nan' for small values. This test compares expl() to exp() . > + if test $gl_cv_func_expl_no_libm = yes \ > + || test $gl_cv_func_expl_in_libm = yes; then > + AC_CACHE_CHECK([checks whether expl is buggy], > + [gl_cv_func_expl_buggy], > + [ > + save_LIBS="$LIBS" > + LIBS="$EXPL_LIBM $FABS_LIBM"
You might assume that fabs is in the same lib as expl? So this FABS_LIBM var is probably best left out, as it's not guaranteed set here. > + AC_RUN_IFELSE( > + [AC_LANG_PROGRAM( > + [[#include <math.h> > +]], [[ double l ; > + int expl_ok = 1 ; > + for (l=-3 ; l < 3 ; l+=0.001) > + expl_ok &= (fabs(exp(l)-expl(l))<1e-10); Is checking this whole range necessary? > + return expl_ok?0:1 ; ]])], > + [gl_cv_func_func_expl_buggy=no], [gl_cv_func_expl_buggy=yes], > + [case $host_os in > + mingw*) gl_cv_func_expl_buggy="guessing no";; > + *) gl_cv_func_expl_buggy="guessing yes";; > + esac]) > + LIBS="$save_LIBS" > + ]) > + if test $gl_cv_func_expl_buggy = yes; then > + dnl TODO: Use gnulib's expl instead of the system's expl > + AC_MSG_NOTICE([Detected buggy expl(), using gnulib's implementatin]) s/in/ion/ > + gl_cv_func_expl_in_libm=no > + gl_cv_func_expl_no_libm=no > + fi You could just move the whole block earlier in the function to line 55, so that the subsequent check of $gl_cv_func_expl_in_libm etc. is significant? thanks! Pádraig.
