An old bug-glibc message for glibc 2.3.1 <http://lists.gnu.org/archive/html/bug-glibc/2003-01/msg00016.html> seemingly didn't get followed up on. Simon Poole reported a similar problem for a crosstool build; see <http://sourceware.org/ml/crossgcc/2004-11/msg00013.html>. The problem is that an __asm__ generates code containing the symbol __i686, but some preprocessor/compiler combinations automatically #define __i686 to 1, which messes up the generated code. On 2004-05-17 a similar problem was fixed in sysdeps/unix/sysv/linux/sparc/sparc32/sysdep.h by renaming the affected symbol; see <http://cvs.savannah.gnu.org/viewvc/libc/sysdeps/unix/sysv/linux/sparc/sparc32/sysdep.h?root=libc&r1=1.13&r2=1.14>. I'll attach a similar (but untested) patch for sysdeps/unix/sysv/linux/i386/sysdep.h.
Created attachment 1838 [details] patch for __i686 problem in sysdeps.h
I have told people several times: __i686.get_pc_thunk.cx is the name of the section gcc uses. There is no changing this here.
Created attachment 1839 [details] revised __i686 patch, which simply undefs the symbol OK, thanks, I didn't know the symbol couldn't be changed. In that case, Wolf's original patch seems apropos and I have attached it, replacing the incorrect patch.
Created attachment 1840 [details] revised __i686 patch, which simply undefs the symbol Fix misspelling in comment.
*** Bug 5283 has been marked as a duplicate of this bug. ***
this isnt a linux-specific issue is it ? in other words, shouldnt the change be done in sysdeps/i386/sysdep.h ?
Created attachment 2151 [details] patch for x86_64
Created attachment 2899 [details] patch for glibc 2.8
Still broken as of f01c2359ebd4ed130ea0bfa67b59db896cb55cd5. Patch in attachment 1840 [details] fixes the problem.
This was fixed as bug 411. *** This bug has been marked as a duplicate of bug 411 ***