Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.
On Tue, Jun 10, 2014 at 09:45:30PM +0200, Mark Wielaard wrote:
> On Tue, 2014-06-10 at 21:25 +0200, Aurelien Jarno wrote:
> > On Tue, Jun 10, 2014 at 08:10:00PM +0200, Mark Wielaard wrote:
> > > On Mon, 2014-06-09 at 18:02 +0200, Aurelien Jarno wrote:
> > > > 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.
> > >
> > > Both issues were GCC bugs now fixed on mainline. See
> > > https://gcc.gnu.org/PR61231 and http://gcc.gnu.org/PR61336.
> > > The first one was not really related to sys/sdt.h at all. The second was
> > > indeed a bug in GCC on alpha triggered by the usage of the "i"
> > > constrained in the sys/sdt.h asm, now fixed.
> >
> > I doesn't seems to be the case. PR61336 is about the sys/sdt.h code
> > triggering an ICE, and it has indeed been fixed. That said it now emits
> > an error instead of an ICE, so sys/sdt.h is still not usable on alpha,
> > as the last comment says:
> >
> > | Richard Henderson 2014-06-02 16:47:20 UTC
> > | The ICE has been resolved.
> > |
> > | Note that the asm in question comes from system tap, which has not been
> > | ported to alpha. So you're probably better off disabling that in your
> > | (e)glibc build too.
>
> I asked Richard and he said that mainline GCC now allows the "i"
> constraint with a symbol, with an asm. So it shouldn't produce an error.
> What error are you seeing?
>
> stap might not know how to interpret such SDT ELF notes. Since systemtap
> is not known to work on alpha (I don't know for other SDT consumers like
> gdb and perf). But that would be independent of building with sys/sdt.h.
> So unless I misunderstood him things should compile fine, even if you
> decided to keep sys/sdt.h enabled for the glibc build on alpha.
>
> Of course, if none of the SDT consumers are known to work on alpha then
> having them might just be a noop and it should also be fine to disable
> them on that platform if you wish. But I don't think that is necessary.
I don't have access to an alpha machine. Michael, could you please
confirm that the patch from PR61336 does remove the ICE, but in addition
allow the file to be compiled?
> > I am therefore re-asking if you can provide a list of architectures
> > where sys/sdt.h is known to work and doesn't have any issues.
>
> As far as I know it builds fine everywhere (modulo any GCC bugs). At
> least I have personally seen it work fine on x86, x86_64, arm, aarch64,
> ppc, ppc64 and s390. I have no experience with other arches. But if any
> arch wouldn't work, then that is a bug that should be fixed of course.
Ok, thanks.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: