|Summary:||gcc defines __i686 macro, causing problems in sysdeps/i386/elf/setjmp.S|
|Product:||glibc||Reporter:||J. Scott Berg <j.scott.berg>|
|Component:||libc||Assignee:||GOTO Masanori <gotom>|
|Severity:||minor||CC:||allan, burtms, carlos_odonell, eggert, glibc-bugs, polacek, rmathew, toolchain|
This lets it build for me
Patch to make it work on NPTL build
Remove tst-cancel17.c patch from the previous
Something was wrong with the line numbers in the previous patch, not sure how that happened...
Description J. Scott Berg 2004-09-25 22:48:30 UTC
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.
Comment 1 J. Scott Berg 2004-10-03 02:00:05 UTC
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!).
Comment 2 J. Scott Berg 2005-04-15 20:29:15 UTC
Created attachment 458 [details] Patch to make it work on NPTL build I upgraded to kernel 184.108.40.206 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.
Comment 3 J. Scott Berg 2005-04-15 20:35:45 UTC
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.
Comment 4 Ulrich Drepper 2005-10-16 00:41:20 UTC
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.
Comment 5 Ranjit Mathew 2005-10-16 02:05:24 UTC
(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.
Comment 6 J. Scott Berg 2006-02-07 20:15:34 UTC
Created attachment 859 [details] Something was wrong with the line numbers in the previous patch, not sure how that happened...
Comment 7 Petr.Salinger 2006-02-08 09:37:56 UTC
> 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 ?
Comment 8 Jakub Jelinek 2006-02-08 09:42:34 UTC
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.
Comment 9 Petr.Salinger 2006-02-08 11:14:29 UTC
> 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
Comment 10 Ulrich Drepper 2006-04-21 18:25:42 UTC
"It hurts when I do this." Then don't. There is no need for a change.
Comment 11 David S. Miller 2010-02-24 13:38:34 UTC
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.
Comment 12 Juergen Daubert 2010-04-15 08:20:07 UTC
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
Comment 13 Burt Silverman 2012-01-19 02:13:32 UTC
(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."
Comment 14 Marek Polacek 2012-01-19 06:32:19 UTC
The GCC now uses the "__x86.get_pc_thunk" prefix.
Comment 15 Burt Silverman 2012-01-21 17:28:06 UTC
(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.
Comment 16 Joseph Myers 2012-02-08 01:47:47 UTC
This is now fixed for 2.16.
Comment 17 Joseph Myers 2012-02-18 00:16:39 UTC
*** Bug 4507 has been marked as a duplicate of this bug. ***
Comment 18 Carlos O'Donell 2012-04-22 19:35:22 UTC
I've checked in an alternate fix for this on the 2.15 branch.