Description of problem: index doesn't work correctly on i686. It prevents openldap package from rebuilding. Actually it may be glibc bug (I hadn't time to investigate it more deep). Version-Release number of selected component (if applicable): m4-1.4.16-6.fc19.i686 How reproducible: Always Steps to Reproduce: 1. echo "index(\`, enable_static, ', \`, enable_shared, ')" | m4 Actual results: 28 Expected results: -1 Additional info: It doesn't work with glibc-2.16.90-11.fc19.i686, but it works correctly with glibc-2.16-7.
Please, resolve this ASAP. I will make a workaround in OpenLDAP till then.
In my opinion this is glibc bug. See this reproducer: #include <stdio.h> #include <string.h> int main(void) { const char *haystack = ", enable_static, "; const char *needle = ", enable_shared, "; char *result; int retval; result = strstr(haystack, needle); printf("'%s'\n", result); retval = result ? result - haystack : -1; printf("%d\n", retval); return 0; } # ./reproducer ', enable_shared, ' 18 With glibc-2.16.90-11.fc19.i686, needle is found in haystack.
This is working fine for me in a mock environment. It may be the case this problem is dependent upon the particular implementation of strstr in use -- there are multiple ones that are selected at runtime based on the processor's capabilities. Can you please attach the contents of /proc/cpuinfo on a system where this is failing so that I can examine the flags and determine which of the strstr implementations is being used. Thanks,
Created attachment 614849 [details] cpuinfo (failing) Attaching requested /proc/cpuinfo from a machine, where the problem presents in i686 mock environment.
Thanks. That processor will use a different implementation than the box I tested on, if I'm reading all the strstr bits correctly. I believe I've got a laptop here with similar capabilities which I can use for testing... Or I can just hack up the sources to force the path that processor would take for testing/debugging purposes.
Appears to be introduced fairly recently by Maxim when optimizing the C strstr.
This should be fixed in rawhide.
I can confirm, that the problem disappeared with gcc-4.7.2-1.fc19.i686 Thanks.
(In reply to comment #8) > I can confirm, that the problem disappeared with gcc-4.7.2-1.fc19.i686 Except that it doesn't have anything to do with gcc. It disappeared with glibc update.
(In reply to comment #9) > Except that it doesn't have anything to do with gcc. It disappeared with > glibc update. Of course (need a coffee): glibc-2.16.90-14.fc19.i686