acinclude: Always assume buggy strtok_r() for glibc < 2.8.

acinclude: Always assume buggy strtok_r() for glibc < 2.8.

Lately our internal build system has been seeing intermittent failures that
I can't explain.  With old glibc versions, the "configure" time check will
pass, but the equivalent (almost identical) "make check" test will fail.
One possibility, I guess, is that occasionally address space randomization
will put valid data at the 0xc0ffee address that the test assumes will
segfault, and another is that some change in compiler optimization flags
is making a difference.  At any rate, I think it's safe to just always
assume that this strtok_r() bug is present whenever glibc before 2.8 is
in use.

Specifically we've seen this happen intermittently when building against
the XenServer DDK 5.6.100 build 39265, which uses glibc 2.5.

Reported-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>