Bugzilla Bug 179353

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.