Bug#974058: Help with an arm64 specific gcc internal error with polymake
On 2020-11-28 07:32 -0400, David Bremner wrote: > Wookey writes: > > > On 2020-11-27 10:28 -0400, David Bremner wrote: > > > >> I'm talking about remove polymake/arm64, not perl. > > > > Right, but perl build-depends on polymake, so with no polymake we > > can't update perl (e.g. for security reasons) > > > > That doesn't make sense to me. Polymake is software for mathematical > research, which happens to be a perl extension. OK. I think I had the wrong end of the stick. I assumed it was a build-dep because Dominic said somewhere in this thread/bugrep that it being broken was blocking the perl transition, so I assumed that it was needed to build perl, but I guess he just meant that everything which is a perl module has to be rebuilt against the current perl before it can migrate? In which case you are quite right, removing polymake does not affect perl updates. Adrian's latest message suggests that the issue is gone in the latest gcc-10 upload so hopefully polymake can stay for now. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#974058: Help with an arm64 specific gcc internal error with polymake
Wookey writes: > On 2020-11-27 10:28 -0400, David Bremner wrote: > >> I'm talking about remove polymake/arm64, not perl. > > Right, but perl build-depends on polymake, so with no polymake we > can't update perl (e.g. for security reasons) > That doesn't make sense to me. Polymake is software for mathematical research, which happens to be a perl extension. apt showsrc perl says: Package: perl Binary: perl-base, perl-doc, perl-debug, libperl5.32, libperl-dev, perl-modules-5.32, perl Version: 5.32.0-5 Maintainer: Niko Tyni Uploaders: Dominic Hargreaves Build-Depends: file, cpio, libdb-dev, libgdbm-dev (>= 1.18-3), libgdbm-compat-dev, netbase , procps [!hurd-any] , debhelper-compat (= 13), zlib1g-dev | libz-dev, libbz2-dev, dpkg-dev (>= 1.17.14), dist (>= 3.5-236), libc6-dev (>= 2.19-9) [s390x] Version: 5.30.3-4 Build-Depends: file, cpio, libdb-dev, libgdbm-dev (>= 1.18-3), libgdbm-compat-dev, netbase , procps [!hurd-any] , debhelper-compat (= 13), zlib1g-dev | libz-dev, libbz2-dev, dpkg-dev (>= 1.17.14), dist (>= 3.5-236), libc6-dev (>= 2.19-9) [s390x]
Bug#974058: Help with an arm64 specific gcc internal error with polymake
On 2020-11-27 10:28 -0400, David Bremner wrote: > I'm talking about remove polymake/arm64, not perl. Right, but perl build-depends on polymake, so with no polymake we can't update perl (e.g. for security reasons) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#974058: Help with an arm64 specific gcc internal error with polymake
Wookey writes: >> At the risk of being repetitive, this is only a workaround for the perl >> transition, it does almost nothing for polymake on arm64. The package is >> still RC buggy since it is compiled with a non-default version of >> gcc. I'm still looking at an arch-specific removal for bullseye. > > What are the implications of that? Wouldn't that make perl unbuildable > on arm64 for the lifetime of the release which sounds like a big > problem for everyone? i.e polymake is now pseudo build-essential. > > Obviously it's bad that polymake can only be built with an older > compiler version, but we are at the mercy of compiler engineers fixing > what appears to be a very old and difficult bug. Removing the package > (and thus security support for perl) doesn't seem like something that > serves our uses very well. > > Have I misunderstood the problem, or is this the situation? I'm talking about remove polymake/arm64, not perl. d
Bug#974058: Help with an arm64 specific gcc internal error with polymake
On 2020-11-27 06:52 -0400, David Bremner wrote: > Wookey writes: >> On 2020-11-17 21:19 +, Dominic Hargreaves wrote: >>> Thanks for your work on this. As of today polymake has been uploaded >>> to use gcc-9 which doesn't have this problem, so the perl transition >>> has been unblocked. >> >> I don't understand how this works, because Alex Coplan was able to reproduce >> the ICE all the way back to gcc6, and it's been in bugzilla since 2012. >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590 >> >> Still, immediate issue worked around and hopefully the compiler will >> get fixed one day. > > At the risk of being repetitive, this is only a workaround for the perl > transition, it does almost nothing for polymake on arm64. The package is > still RC buggy since it is compiled with a non-default version of > gcc. I'm still looking at an arch-specific removal for bullseye. What are the implications of that? Wouldn't that make perl unbuildable on arm64 for the lifetime of the release which sounds like a big problem for everyone? i.e polymake is now pseudo build-essential. Obviously it's bad that polymake can only be built with an older compiler version, but we are at the mercy of compiler engineers fixing what appears to be a very old and difficult bug. Removing the package (and thus security support for perl) doesn't seem like something that serves our uses very well. Have I misunderstood the problem, or is this the situation? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
