Eric Blake <e...@byu.net> writes: > According to Simon Josefsson on 6/13/2009 10:43 AM: >>> Looks pretty much like one of the glibc memchr bugs that were recently >>> fixed: >>> <http://sourceware.org/bugzilla/show_bug.cgi?id=10162> >> >> I'm not sure, the machine where this fails runs glibc 2.7 and the bug >> appears to be about glibc 2.10? The machine appears to be a debian >> lenny machine. It is GCC compile farm host gcc60, if you have an >> account. > > I don't (yet, although I should look into getting one). Hey, does the > strstr test also fail on this machine, even with the fixed memchr.m4? The > logs you pointed to were for SASL, which did not use the strstr module. > If test-strstr fails (which I suspect it will), then I need to also modify > strstr.m4 to declare that the system strstr needs replacing if memchr is > broken.
I have started a build of gnulib on that host, and it will run daily from now on. But testing strstr (using current gnulib) manually passes: ... checking for getpagesize... yes checking for mmap... yes checking for MAP_ANONYMOUS... yes checking for memchr... yes checking whether memchr works... no checking bp-sym.h usability... no checking bp-sym.h presence... no checking for bp-sym.h... no checking whether strstr works in linear time... no ... PASS: test-strstr I checked, and the gnulib strstr replacement is used. /Simon
