Re: glibc regression on alpha with 2.34+

Hi Adrian,

On 14.12.22 20:51, John Paul Adrian Glaubitz wrote:
> [...]
>> Can we be sure that this reproducer identifies the same problem than
>> the build failures from the original post ([1])?
>>
>> [1]: https://lists.debian.org/debian-alpha/2022/11/msg00003.html
>
> Well, this is how I identified that there was a problem with glibc on
> alpha.
>
> I built the packages manually with the testsuite enabled and installed them
> into a chroot for testing which resulted in a segfault when dpkg tried to
> configure the libc-bin package.
>
> I assume the many testsuite failures are a direct result of this bug which
> just causes many tests to segfault. We had a similar problem on sparc64
> where
> a single bug in the static build caused many testsuite failures.

I see.

> Interestingly, when I checkout the tag glibc-2.34 and disabled the
> _dl_minsigstacksize symbol
> in "struct rtld_global_ro {}" again with the following hack, I'm no
> longer getting a segfault
> but a floating point exception:
>
> [...]
>
> Could you verify this on your DS-15?

I'll do that tomorrow. The thing is that this diff doesn't apply cleanly:

```
root@ds15:/srv/storage/glibc# git checkout glibc-2.34
Note: switching to 'glibc-2.34'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

[...]
HEAD is now at ae37d06c7d Update ChangeLog.old/ChangeLog.23.

root@ds15:/srv/storage/glibc# patch -p1 < ../../glibc-fix.patch
patching file elf/dl-sysdep.c
Hunk #1 FAILED at 116.
Hunk #2 FAILED at 185.
2 out of 2 hunks FAILED -- saving rejects to file elf/dl-sysdep.c.rej
patching file elf/rtld_static_init.c
patching file sysdeps/generic/ldsodefs.h
patching file sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
Hunk #1 succeeded at 22 with fuzz 1.
patching file sysdeps/unix/sysv/linux/sysconf.c
Hunk #1 succeeded at 84 with fuzz 2.
```

Not sure why, shouldn't we have the same source state? Should I try to
apply the rejected stuff manually?

Cheers,
Frank