alpha-unknown-linux-gnu-gcc ../sysdeps/unix/sysv/linux/alpha/sigsuspend.S -c -I../include -I/var/tmp/portage/sys-libs/glibc-2.5-r2/work/build-default-alpha-unknown-linux-gnu-nptl/signal -I/var/tmp/portage/sys-libs/glibc-2.5-r2/work/build-default-alpha-unknown-linux-gnu-nptl -I../nptl/sysdeps/alpha/elf -I../sysdeps/alpha/elf -I../sysdeps/unix/sysv/linux/alpha/alpha -I../nptl/sysdeps/unix/sysv/linux/alpha -I../sysdeps/unix/sysv/linux/alpha -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/ieee754/ldbl-64-128 -I../sysdeps/ieee754/ldbl-opt -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -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 -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/alpha -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/alpha/fpu -I../nptl/sysdeps/alpha -I../sysdeps/alpha -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/alpha/soft-fp -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/alpha-unknown-linux-gnu/4.1.1/include -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -DASSEMBLER -Wa,--noexecstack -Wa,--noexecstack -o /var/tmp/portage/sys-libs/glibc-2.5-r2/work/build-default-alpha-unknown-linux-gnu-nptl/signal/sigsuspend.os -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.5-r2/work/build-default-alpha-unknown-linux-gnu-nptl/signal/sigsuspend.os.dt -MT /var/tmp/portage/sys-libs/glibc-2.5-r2/work/build-default-alpha-unknown-linux-gnu-nptl/signal/sigsuspend.os ../sysdeps/unix/sysv/linux/alpha/sigsuspend.S: Assembler messages: ../sysdeps/unix/sysv/linux/alpha/sigsuspend.S:41: Error: previous CFI entry not closed (missing .cfi_endproc) ../sysdeps/unix/sysv/linux/alpha/sigsuspend.S:43: Error: .cfi_endproc without corresponding .cfi_startproc make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.5-r2/work/build-default-alpha-unknown-linux-gnu-nptl/signal/sigsuspend.os] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.5-r2/work/glibc-2.5/signal' make[1]: *** [signal/subdir_lib] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.5-r2/work/glibc-2.5' make: *** [all] Error 2 !!! ERROR: sys-libs/glibc-2.5-r2 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 4111: Called src_compile glibc-2.5-r2.ebuild, line 1169: Called toolchain-glibc_src_compile glibc-2.5-r2.ebuild, line 272: Called die Reproducible: Always Steps to Reproduce: 1.enable nptlonly in /etc/make.conf 2.run emerge --update --newuse system 3.
Not a portage bug.
ive already moved this upstream ... we're just waiting for them to fix it
*** Bug 179378 has been marked as a duplicate of this bug. ***
Long time (more than one month) without a fix from UPSTREAM and our stable glibc is still broken. May be is time to fix it by ourselves. There is a workaround by updating bintuils to version >2.17.50.0 but they are not ready to stable yet. @SpanKY: What do you think? Wait to UPSTREAM or patch the gentoo glibc? Baojun Wang wrote to alpha mailling list and found a patch applied in debian which seems to be related to sigsuspend: http://archives.gentoo.org/gentoo-alpha/txtqGRJiVv5sv.txt I've not tested it yet, but can do it if patching our glibc is the way to follow. Thanks.
(In reply to comment #4) > @SpanKY: What do you think? Wait to UPSTREAM or patch the gentoo glibc? > Baojun Wang wrote to alpha mailling list and found a patch applied in debian > which seems to be related to sigsuspend: > http://archives.gentoo.org/gentoo-alpha/txtqGRJiVv5sv.txt Ouch! I failed to read Baojun's comment about the patch: it really doesn't help to solve the current bug. Sorry for the noise.
(In reply to comment #4) HPPA actually uses binutils-2.17.50.0.12 because glibc-2.5 didn't work for 'em with any stable version of binutils. bug 168131. Ferdy said he doesn't want to stabilize any testing version of binutils, so... :)
that bug is unrelated ... i mentioned that upstream a while ago about glibc-2.5 and we've already integrated the upstream fix: http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.5/6010_all_alpha-glibc-2.5-sigsuspend-nocancel.patch
(In reply to comment #7) > that bug is unrelated ... i mentioned that upstream a while ago about glibc-2.5 > and we've already integrated the upstream fix: > http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.5/6010_all_alpha-glibc-2.5-sigsuspend-nocancel.patch > I know it's unrelated, but stable glibc fails on alpha with stable binutils. I'm just saying that HPPA has a testing version(2.17.50.0.12) of binutils stable because glibc-2.5 didn't work for them with <2.17.50.0.12. glibc with stable binutils(2.17), fails using patchset 1.6, but works with patchset 1.5. However, if you use binutils-2.17.50.0.16, with patchset 1.6 it works but with 1.5 fails. So, the solution is stabilizing binutils-2.17.50.0.16, since they fix this bug and the ld slowness too. But ferdy said: we're not going to stabilize a testing version of binutils. So...
i was responding to Jose any version >=2.17.50.0.7 would be OK ... i'm not sure glibc is broken here
(In reply to comment #9) > i was responding to Jose > Oops :) > any version >=2.17.50.0.7 would be OK ... i'm not sure glibc is broken here > That's up to ferdy/yoswink.
yeah it isnt a bug in glibc, newer glibc requires a feature added between 2.17.50.0.6 and 2.17.50.0.7 ... allowing nested cfi directives in subsections http://sourceware.org/ml/binutils/2006-10/msg00378.html
(In reply to comment #9) > > any version >=2.17.50.0.7 would be OK ... We have marked ~alpha 2.17.50.0.16 version since 14th May. So probably this our best candidate to stable (unless a dark reason appears). Mike, give an ok and we'll move all devs chroots to this version and start some days of heavy testing over it. Thanks.
i'm not aware of any problems with 2.17.50.0.13+ ... i run the latest on my machines as soon as they're released so i tend to catch the more common errors (2.17.50.0.17 atm) moving people over should be OK i think
I reemerged world in a newly created chroot with that binutils version, everything went fine except the already know failures, well, just one, sandbox. I also made a copy of my main chroot and reemerged world, everything fine. Plus Brian and Tobias have been running those versions for a long time(since it has been in the tree). Sandbox fails with stable binutils, so that's not the problem. So Jose, already tested on my part :)
I see no reason to wait more having the stable glibc broken. 2.17.50.0.16 stable. Thanks guys.