Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.
reopen 700760
tag 700760 + moreinfo
clone 750996
reassign -1 750996 systemtap-sdt-dev
retitle 750996 systemtap-sdt-dev: breaks eglibc build on alpha
block 700760 by 750996
thanks
On Mon, Jun 09, 2014 at 10:13:05PM +1200, Michael Cree wrote:
> Source: eglibc
> Version: 2.19-1
> Severity: important
> User: debian-alpha@lists.debian.org
> Usertags: alpha
> Justification: fails to build from source but built in the past
> X-Debbugs-CC: debian-alpha@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?)
systemtap-sdt-dev was supposed to be something transparent for the
glibc, but in practice it causes build failure on at least on alpha (see
above). Looking at the BTS, I see it also causes problems with GCC, so I
am a bit concerned on other side effects we might haven't seen yet.
systemtap-sdt-dev was supposed to be arch:all to be able to be used on
all architecture, but in practice it doesn't seems to be the case. Could
you please to switch it back to a specific architecture list where it
actually works? In the meantime we are going to revert SDT support in
eglibc, thus reopening the bug.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: