I have three systems (two i386, one x86-64) on which glibc-2.7 fails to compile, all with the same error: x86_64-pc-linux-gnu-gcc ../sysdeps/i386/fpu/s_frexp.S -c -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/var/tmp/portage/sys-libs/glibc-2.7/work/build-x86-x86_64-pc-linux-gnu-nptl/math -I/var/tmp/portage/sys-libs/glibc-2.7/work/build-x86-x86_64-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/include -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -DASSEMBLER -DGAS_SYNTAX -Wa,--noexecstack -Wa,--noexecstack -o /var/tmp/portage/sys-libs/glibc-2.7/work/build-x86-x86_64-pc-linux-gnu-nptl/math/s_frexp.os -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.7/work/build-x86-x86_64-pc-linux-gnu-nptl/math/s_frexp.os.dt -MT /var/tmp/portage/sys-libs/glibc-2.7/work/build-x86-x86_64-pc-linux-gnu-nptl/math/s_frexp.os ../sysdeps/i386/fpu/s_frexp.S: Assembler messages: ../sysdeps/i386/fpu/s_frexp.S:66: Error: invalid identifier for ".ifdef" ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: unrecognized symbol type "" ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1' ../sysdeps/i386/fpu/s_frexp.S:66: Error: expected comma after name `' in .size directive ../sysdeps/i386/fpu/s_frexp.S:66: Error: ".endif" without ".if" ../sysdeps/i386/fpu/s_frexp.S:66: Error: junk `.get_pc_thunk.dx' after expression I put the relevant info (build.log, environment, emerge --info, make.conf) for each of the three systems up at: http://www.lwithers.me.uk/usr/share/gentoo-bugs/2007-12-09--glibc-2.7/ Let me know if more data is needed. This would appear to be connected to this bug: http://sourceware.org/bugzilla/show_bug.cgi?id=5283
post all relevant information in the bug, not in external URIs. post the full build log as an attachment, not just a small snippet. the __i686 issue was fixed a long time ago (over a year and a half ago). it only came up on systems where the user had changed how their gcc compiled.
Created attachment 138154 [details] build.log from chrysocolla
Created attachment 138155 [details] emerge --info from chrysocolla
Created attachment 138157 [details] environment from chrysocolla
Created attachment 138159 [details] make.conf from chrysocolla
Created attachment 138161 [details] build.log from molybdenum
Created attachment 138162 [details] emerge --info from molybdenum
Created attachment 138164 [details] environment from molybdenum
Created attachment 138165 [details] make.conf from molybdenum
Created attachment 138169 [details] build.log from roentgenium
Created attachment 138171 [details] emerge --info from roentgenium
Created attachment 138173 [details] environment from roentgenium
Created attachment 138175 [details] make.conf from roentgenium
I hope this information is what you need, and that it's OK for me to re-open the bug report. When you mention that "it only came up on systems where the user had changed how their gcc compiled.", I wonder what you mean? I have the vanilla use flag turned on in gcc, binutils etc. Otherwise I don't think I've done anything odd. Further, glibc-2.7 does compile on the other three systems I maintain, which I don't think I've done anything particularly different on (the other three all have X on I suppose, but I can't see that making a difference).
USE=vanilla is provided as a reference. of course you're going to get a glibc build failure if you have this turned on because you just told the ebuild not to apply the patch that fixes the problem you're hitting.
*** Bug 203205 has been marked as a duplicate of this bug. ***
*** Bug 261681 has been marked as a duplicate of this bug. ***
*** Bug 262520 has been marked as a duplicate of this bug. ***
*** Bug 263862 has been marked as a duplicate of this bug. ***
*** Bug 264183 has been marked as a duplicate of this bug. ***
*** Bug 284502 has been marked as a duplicate of this bug. ***
I understand why +vanilla doesn't work, but is there some way to know the smallest patchset deemed neccessary to build at all? I'm currently doing trial-and-error to find it. The basic problem is I suspect some patches to cause problems, so I try to be as close to vanilla as can be.
*** Bug 325607 has been marked as a duplicate of this bug. ***
*** Bug 392231 has been marked as a duplicate of this bug. ***
