It takes a long time on my autobuild machine as well (debian x86
stable). Running for 14 minutes at 100% CPU and counting. Does it have
to run the long-running self-tests each time?
/Simon
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello, and a Happy New Year,
>
> quoting memmem.m4:
>
> AC_CACHE_CHECK([whether memmem works], [gl_cv_func_memmem_works],
> [AC_RUN_IFELSE([AC_LANG_PROGRAM([#include <string.h>],
> [return !memmem ("a", 1, NULL, 0);])],
> [gl_cv_func_memmem_works=yes], [gl_cv_func_memmem_works=no],
> [dnl pessimistically assume the worst, since even glibc 2.6.1
> dnl has quadratic complexity in its memmem
> gl_cv_func_memmem_works=no])])
>
> This sets gl_cv_func_memmem_works=yes in the non-cross-compiling case,
> tested on GNU/Linux with glibc 2.3.6, which in turn causes the
> test-memmem.c test to take an awful lot of time to complete (I killed
> it after several minutes). I noticed this with git master M4.
>
> I suggest that either the testsuite test use some time limit (alarm?),
> or the configure test tries to expose the quadratic complexity, or the
> configure test assume `no' on systems where we know libc's memmem to be
> insufficient.
>
> Cheers,
> Ralf
