On Mon, Jun 09, 2014 at 10:13:05PM +1200, Michael Cree wrote: > Source: eglibc > Version: 2.19-1 > Severity: important > User: debian-al...@lists.debian.org > Usertags: alpha > Justification: fails to build from source but built in the past > X-Debbugs-CC: debian-al...@lists.debian.org > > eglibc FTBFS on alpha for two reasons, firstly, due to the inclusion of > systemtap headers and, secondly, because of what might be broken > FUTEX_CLOCK_REALTIME support in the kernel. > > The systemtap header inclusion introduces an invalid unsplit symbol > reference to global_max_fast in inline asm leading to a failure to compile > malloc/malloc.c, which is the reason for the compiler ICE seen in the build > log at: > > http://buildd.debian-ports.org/status/fetch.php?pkg=eglibc&arch=alpha&ver=2.19-1&stamp=1401942698 > > The compiler ICE is now fixed in gcc upstream (PR target/61336) to a > graceful error exit which won't help us in getting eglibc built on alpha. > > So my question: can we have the systemtap-sdt-dev build-dep removed from > eglibc for a build on Alpha? (And what are the implications of that? > Presumably nothing since even a number of official arches are not supported > by systemtap?)
According to its maintainers GDB could now use the systemtap probes to improve debugging. As such it should work on all architectures, even the ones which don't have systemtap support. That said what happen is unfortunate, and given that it seems to also cause build failures of gcc, I am going to revert this commit until the situation is more clear. > With the systemtap headers removed the build gets to the test-suite with > ominous looking failures in tst-rwlock6, tst-rwlock11, tst-rwlock12, etc. > The assumption __ASSUME_FUTEX_CLOCK_REALTIME activated at kernel version > 2.6.29 in the eglibc source would appear to be false for Alpha, or maybe the > test suite failures are due to a broken kernel (I tested with kernels 3.10.x > and 3.14.x and the build daemon is still on 3.13.x; all fail). Whatever, > undefining __ASSUME_FUTEX_CLOCK_REALTIME results in correct behaviour for > the rwlock tests. I attach a patch for that. Looking at the kernel code, clock realtime futexes have also been introduced in 2.6.29 on Alpha, as it is done in architecture independent part. My guess is that disabling __ASSUME_FUTEX_CLOCK_REALTIME is exercising a different code path, and that real bug is in the glibc alpha specific code of __ASSUME_FUTEX_CLOCK_REALTIME, for example in lll_futex_timed_wait_bitset which have been added relatively recently. > Index: eglibc-2.19/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h > =================================================================== > --- eglibc-2.19.orig/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h > +++ eglibc-2.19/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h > @@ -93,4 +93,7 @@ > # define __ASSUME_FDATASYNC 1 > #endif > > +/* Appears to have never worked on Alpha. */ > +#undef __ASSUME_FUTEX_CLOCK_REALTIME > + > #endif /* _KERNEL_FEATURES_H */ It's something we can add for 2.19, but as code is currently being cleanup on the upstream side to remove the fall back code for things that are always defined, this solution might not work in the near future. It therefore might be better to fix the real problem instead. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
