Red Hat Bugzilla – Bug 858274
index doesn't work correctly on i686 (causing FTBFS for openldap)
Last modified: 2016-11-24 10:42:34 EST
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):
Steps to Reproduce:
1. echo "index(\`, enable_static, ', \`, enable_shared, ')" | m4
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:
const char *haystack = ", enable_static, ";
const char *needle = ", enable_shared, ";
result = strstr(haystack, needle);
retval = result ? result - haystack : -1;
', enable_shared, '
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.
Created attachment 614849 [details]
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
(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