Bug#335286: gcc: Internal error compiling lilypond on hppa

[Thomas Bushnell BSG <tb@becket.net>]

Steve Langasek <vorlon@debian.org> writes:

> This is the single most common build failure on arm, hppa, and m68k right
> now, and has affected literally dozens or hundreds of other packages.  I
> do kinda know it on sight by this point.
>
>> Moreover, this bug should remain filed against gcc-4.0, because it is,
>> in fact, a bug in gcc 4.0.  There is a *separate* bug filed against
>> lilypond referring to this one.  This bug should remain open and filed
>> against gcc-4.0 until a fix is uploaded for Debian.
>
> That's fine; I had reassigned it to lilypond before I received the mail that
> you had filed a separate bug there.  But this is a duplicate of 323133, so
> merging.  It also is not a release-critical bug because there is a valid
> workaround for all affected packages, and in spite of the sizeable impact
> it's non-trivial to fix and has been triaged out of necessity.

I find it ludicrous to think that the best solution here is to force a
jillion maintainers to workaround the bug and recompile.

I recall not too recently that you thought hacking version numbers was
an acceptible solution, but I guess that's when your package was the
one that was being asked to have a workaround.  

Hrm, seriously though, why not backport the fix (though the upstream
bug record doesn't seem to show one yet, while the Debian bug record
says fixed-upstream)?  Or, failing that, take gcc-4.0 out of use on
arm, hppa, and m68k?

I see no necessity for "triaging" the bug; this is an excellent reason
simply not to have gcc-4.0 in the archive on the affect archs.
Certainly it should not be in testing!  

Surely this is a canonical example of a release-critical toolchain
bug?

Thomas