Since gcc-3.4.2 (and earlier versions) define the __i686 macro on a pentium3 system, things like __i686.get_pc_thunk.cx get mangled. Thus, sysdeps/i386/elf/setjmp.S won't compile on a pentium3 (and presumably pentium2 also). This is 25 Sep 2004 CVS.
Created attachment 219 [details] This lets it build for me This lets is build and everything seems to work. I'm not sure that this is the best of the many sysdep.h's to put it in (or even that this is the best thing to do!).
Created attachment 458 [details] Patch to make it work on NPTL build I upgraded to kernel 2.6.11.7 and built a nptl glibc (2.3.5 release). Turns out the old patch didn't fix things with NPTL. Things seem to work with this patch. Note that I removed the #define from sysdep.h and instead made the #define's more narrowly targeted. Also, unstead of #undef'ing __i686, I defined it to itself as suggested by a message I found on a mailing list somewhere. I realized that I'm getting __i686 defined because I configured my gcc-3.4.3 build with --with-cpu=pentium3 --with-arch=pentium3 --with-tune=pentium3.
Created attachment 459 [details] Remove tst-cancel17.c patch from the previous Not paying attention, I left a workaround for the tst-cancel17 problem in that patch. New version has it removed.
We don't pass -march=i686 or equivalent to gcc when used on assembler files. Unless you do something wrong (like adding the -march parameter to CC or so) there is no problem.
(In reply to comment #4) > We don't pass -march=i686 or equivalent to gcc when used on assembler files. > Unless you do something wrong (like adding the -march parameter to CC or so) > there is no problem. Well, the "-march" bit gets added automatically if the compiler was built with "--with-arch=pentium3". If I'm building a GCC for use on only my machine, I would build it like this. The real questions are: 1. Does glibc *really* have to use stuff named "__i686", etc.? 2. What good does GCC achieve by predefining "__i686" when "-march=i686"? I know you guys are not particularly interested in build failure reports for glibc, but this particular one seems like something that can easily be resolved between glibc and GCC.
Created attachment 859 [details] Something was wrong with the line numbers in the previous patch, not sure how that happened...
> We don't pass -march=i686 or equivalent to gcc when used on assembler files. > Unless you do something wrong (like adding the -march parameter to CC or so) > there is no problem. Even if -march is not passed, some predefined macros are used, depending on compiler target. Try something like: touch a.S gcc -dD a.S -E Would be possible to use name i.e. __i686_get_pc_thunk.reg instead of __i686.get_pc_thunk.reg ?
No, because __i686.get_pc_thunk.* is what GCC uses internally. Calling it differently means it can't be merged any longer with GCC created pads.
> No, because __i686.get_pc_thunk.* is what GCC uses internally. And what about using patch based on one proposed in http://sources.redhat.com/ml/libc-alpha/2002-10/msg00157.html Now it should go into sysdeps/i386/sysdep.h
"It hurts when I do this." Then don't. There is no need for a change.
Ulrich, it's the default on some distributions, and now even Fedora 12 falls into this category. The compiler people or whoever decided to put that __i686 thing into the CPP namespace made a mistake. Alternatively a different name for the getpc thunks could have been chosen. Either way we're stuck with it and have to address it somehow. Wishing it didn't happen won't fix the build failures every single person who tries to build glibc (with default settings) on Fedora 12 is going to see now.
The whole issue became a new quality, because gcc 4.5.0 always set unconditionally -march=pentiumpro if gcc was build for i686. Please see my rejected bug report for gcc, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750
(In reply to comment #11) > Ulrich, it's the default on some distributions, and now even Fedora 12 falls > into this category. > > The compiler people or whoever decided to put that __i686 thing into > the CPP namespace made a mistake. Alternatively a different name for > the getpc thunks could have been chosen. > > Either way we're stuck with it and have to address it somehow. Wishing it > didn't happen won't fix the build failures every single person who tries > to build glibc (with default settings) on Fedora 12 is going to see now. > I have confirmed that __i686 does not belong in the CPP namespace. I did this by carefully searching the "Using the GNU Compiler Collection" document v4.6.2 for both "macro" and "__". The onus is on the compiler folks to either re-document the compiler, or to remove __i686. Having said that, I found that I could build glibc by adding "-U__i686" to ASFLAGS.o and ASFLAGS.os in sysdeps/i386/i686/Makefile. However, I was not successful doing "make check."
The GCC now uses the "__x86.get_pc_thunk" prefix.
(In reply to comment #14) > The GCC now uses the "__x86.get_pc_thunk" prefix. Thanks, Marek. So if I understand, the glibc source should be changed accordingly, __i686.get_pc_thunk -> __x86.get_pc_thunk. That will remove the conflict. Anybody feel free to contact me if I can be of any assistance.
This is now fixed for 2.16.
*** Bug 4507 has been marked as a duplicate of this bug. ***
I've checked in an alternate fix for this on the 2.15 branch.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.